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.