Tag Category Rename in vCenter – Location Property in Veeam Job Objects Not Updating

[Kosk]

Hi everyone,

We’re currently working on standardizing our VM Tagging structure across multiple vCenters, and I wanted to share an observation and ask for some guidance regarding how Veeam handles renamed Tag Categories.

Scenario:

We use VM Tags to dynamically populate Veeam jobs.
These Tags are organized under a specific Tag Category.
To standardize naming conventions, we renamed the Tag Category in one of our vCenters (we did not create a new category or reassign tags—just renamed the existing one).
What We Observed:

After renaming the Tag Category, all jobs continued to function correctly:
VMs are still being processed as expected.
Disk exclusions are still applied correctly.
(Pending verification: Application-aware processing objects still seem to work without needing to re-add them.)
So far, so good.

The Question:

Using PowerShell:

When we run:
Find-VBRViEntity
we can see the updated Tag Category name in the path.

However, when we inspect job objects using:
$job | Get-VBRJobObject | Select-Object *
the "Location" property still shows the old Tag Category name.

We’re wondering:

Is there a way to refresh or update this value so that the Location property reflects the new Tag Category name?

We’re looking for a way to do this programmatically, ideally without having to remove and re-add the objects to the job.

Why This Matters:

We rely on the Location property for reporting and auditing.
Having outdated values could lead to confusion or misinterpretation of job configurations.
Any insights, PowerShell tips, or internal behavior explanations from the Veeam team or community would be greatly appreciated!

Thanks in advance!

[david.domask]

Hi Kosk,

Give this thread a read as this really comes down to how Job Objects and Find-VBRViEntity work. While the topic creator wasn't using tags, the same concept applies.

I'm not able to test it directly this week, but I'm curious if the location updates for you as well after you've changed the category and run the jobs; I'm guessing "no" based on your answer, but if you could confirm it would be great. With Tags I don't think it will do this automatically but I haven't tested it yet.

If it doesn't, fetching the tags with the correct category with Find-VBRViEntity and then updating the jobs with the "new" tags will give you a Location property value with the correct Category, I'm just not sure at the moment if it's required to do this. (will test next week if you aren't able to test at the moment)

[Kosk]

Hi David

I ran the job after changing the Category Name, and while the job itself worked fine, I can confirm that the Location value doesn’t update when using TAGS—neither in the GUI nor through PowerShell.

Now I’m trying to figure out the cleanest way to get the objects to reflect the updated category.

Would it be better to:

Re-add them using Add-VBRViJobObject and then remove the old ones with Remove-VBRViJobObject,
or
Just update the string directly using Set-VBRJobOptions?

One thing I’m a bit concerned about with Add-VBRViJobObject is that it might mess with existing settings—like App-Aware processing or Disk Exclusion rules. Not sure if those get reset or need to be reconfigured after re-adding.

Thanks!

[david.domask]

Hi Kosk,

Thanks for the information. I wasn't confident it would update like in the other thread since Tags are handled a bit differently than folders in VMware (tags are a separate entity entirely that VMs sit under, so kind of makes sense it wouldn't update).

> Re-add them using Add-VBRViJobObject and then remove the old ones with Remove-VBRViJobObject,

Use this.

As for the custom application aware processing and exclusion entries, these will NOT be reset/overwritten, but they will also not be cleared, meaning the existing entries will remain in the job, but they won't do anything but take up space. You can remove the old exclusions/entries with Remove-VBRViJobObject. For VSS, Set-VBRJobObjectVssOptions is necessary; observe the note on that page, as the cmdlet will _overwrite_ the existing Set-VBRJobObjectVSSOptions, so you can simplify this a bit by just creating an array of the new VBRJobObjectVSSOptions and then overwrite the existing ones with this cmdlet.

[Kosk]

Thanks for the clarification regarding Set-VBRJobObjectVssOptions and how it overwrites existing entries.

Regarding VSS Options, we’re using a dedicated LogShipping server for each VSSObject, although all sites point to the same LogShipping server. What I’ve noticed when working with VSSOptions objects in PowerShell is that the LogShipping server isn’t explicitly specified in the object. There’s a property to check if AutomaticProxy is enabled, but no clear identifier (like a ProxyID) to determine which proxy is actually selected.

This makes implementation tricky, especially since applying new settings via Set-VBRJobObjectVssOptions will override everything to default unless all parameters are explicitly defined.

Is there any known method or workaround to retrieve the ProxyID or identify the LogShipping server used in the current VSS settings?

[Kosk]

Looking at New-VBRJobVssOptions properties looks like you can only set "GuestProxyAutoDetect" on True/False, and I cannot find any property to set any ID to select a LogShipping Server

[david.domask]

Indeed, right now no supported means for setting the LogShipping Server per VSS object :/

Will note this for improvement; was able to find an unsupported method for a workaround however. Add the Job VSS Objects as you normally would and use Set-VBRJobObjectVssOptions to disable automatic proxy selection. Then, use the following unsupported method:

Code: Select all

[Veeam.Backup.Core.COijProxy]::Create($jobVssObject.Id,$logShippingServer.id,"BackupSQL")

First argument is the job object ID returned from Get-VBRJobObjects
Second argument is the desired log shipping server ID returned from Get-VBRServer
Third argument is an enum from one of the following as needed for your log shipping: BackupSql, BackupOracle, BackupPostgreSql

Naturally you can have multiple entries for the same job object but different Log Shipping types, just repeat the same command with the desired type.

Again, unsupported, so if there are issues you'll need to seek help here on the forums.

[Kosk]

Thanks David,

Good to know that will be listed as improvement.

About the unsupported method, hopefully we will use this "fix" only once, as we don't plan to rename TAG Category often

For "Guest Interaction Proxy" in Guest Processing, I think it have the same situation, where you can only now if Automatic is true/false, could you provide with any method to modify that?

Last question, I already tried to update a TAG pointing to the right Category Name. App-Aware setting were not removed, but not applying as you already said.
In Applications, we are adding manually each object with his own settings, and TAG Object is set to "Disable application processing" so it only process the objects that we want, not all VM's inside the TAG.
Adding the new TAG, makes this configuration inside "Application" return to his defaults, so it will process all VM's on the TAG if we don't disable it.
Didn't saw any VSSChild object that was the TAG itself, so I don't know how to disable this default entries inside "Applications"

If we can solve this last question + your workaround for specify LogShipping + Guest Interaction Proxy, we can make sure that all jobs are reporting the correct location for TAGS.

Also, would be perfect that Veeam updates this string automatically in the future as already do for other objects type.

Thanks!

[david.domask]

Indeed, hopefully this is a "one and done" deal, and would be great to have official support.

> For "Guest Interaction Proxy" in Guest Processing, I think it have the same situation, where you can only now if Automatic is true/false, could you provide with any method to modify that?

This works very similarly, see my post here for doing the same with Guest Interaction Proxies. Regrettably it also requires unsupported methods. Same story with supportability, we need to flesh out the cmdlets a bit more here for Guest Interaction Proxy management.

> Didn't saw any VSSChild object that was the TAG itself, so I don't know how to disable this default entries inside "Applications"

The Tag will be returned by Get-VBRJobObject; save the Tag object to a variable and then set the new VSSOptions for it as necessary.

[Kosk]

Thanks, that looks well

One last question...sorry

Is there any way we can check the actual ID for LogShipping and GIP? So we can "clone" the settings before remove the old one and use the same ID without find the correct one in our +200 proxies...
If not we will need to create a defined table, to point each job to the correct ID, or something like that pre-defined to run the fix...

Thanks!

[david.domask]

Happy to help.

Unfortunately no supported means for retrieving either, but both unsupported methods have a way to fetch this information.

[Veeam.Backup.Core.COijProxy]::GetOijProxiesByProxy(<Log Shipping Server ID>)
[Veeam.backup.Core.CJobProxy]::GetJobProxies(<Job ID>)

Pass the log shipping server ID from Get-VBRServer to get an output like below, where you can parse out the JobID and server ID -- you can build a list by iterating over your managed servers and writing the results to array, example output:

Code: Select all

Id      : 23c9ca9a-2531-4ec4-ac58-ceeedb00ac68
ProxyId : 6745a759-2205-4cd2-b172-8ec8f7e60ef8
OijId   : 99ded2da-26b5-446d-925d-73fcc6f6910d
Type    : BackupSql
Info    : Veeam.Backup.Model.COijProxyInfo
Oij     : Id: [99ded2da-26b5-446d-925d-73fcc6f6910d], ObjectId: [04c0746b-1342-426f-8d3d-27a739b5a7e8], JobId:
          [2185bad2-68c2-4936-a2c0-a50299829aae]FolderId: [00000000-0000-0000-0000-000000000000]
          Location: [some-vcenter.local\Folder], Type: [Include], ApproxSize:
          [285903683584]
          VssOptions: [VssSnapshotOptions: [Enabled: [True], ApplicationProcessingEnabled: [True], IgnoreErrors:
          ...[truncated results]

Pass a Job ID from Get-VBRJob to get the Guest Interaction Proxies; you can similarly iterate over all your Vmware/HyperV jobs and write any results to array to get a list.

[Kosk]

Hi David,

Thanks, I get all the info I need, but still trying to figure out how to relate all these info.

Do you think we can get official support from Veeam Support for these topic? I'm guessing that could be easier doing it by SQL or any other method.... we juts need to update a single string

Thanks for all your help