Tags during Restore

[Vitaliy S.]

A quick update on this entire thread > if you add a "TemporaryResource" tag (the one we use) to the policy then the issue will be gone. Thanks!

[kbouchard]

Hi Vitaliy,
Where we can add temporary tag on the ressource group?

[Vitaliy S.]

You can add it in the policy configuration. Here is a sample screenshot to help you: http://prntscr.com/kKULdHfC9bZz

[Desiderat]

Hi all,
I'll bump this topic up. We've faced the same issue in our Azure envs (Case #05786299 on Veeam Support).
Like the topic starter, we have a policy (or it would be better to say 2 policies: one checks tags on RGs and another - on any other resource) that denies any resource creations if a few mandatory tags were not set to them(values don't matter). In our case, adding a "TemporaryResource" tag to the policy will not help us, because the policy will check resources for other mandatory tags.

From our perspective, it would be great if temporary resources would inherit tags from restored items or, at least, if we could create some static staging resource group by ourselves and give it to VBAZ (in the second case we could add exclusion to that RG).

[nielsengelen]

Hi Oleh, understood. We'll look into it for enhancement in the future but I can't provide an ETA for when it will be fully resolved.

[DavidAmerica]

Parent topic: "Case # 07196024 - Request Veeam Support for Advice to Circumvent Tagging Policy During Restore Operation"

Hi Everyone,

Recently I carried out a routine VM restore, back into the VM's original home location. The process failed due to a subscription tagging policy put in place by the department draconian administrator. The tagging policy is said to be a mandatory measure put in place by senior management, as to enforce ownership tracking and accounting cost control, and therefore it is not a negotiable term that I can request to do away with. The problem is that the algorithm for Veeam's SPA (service principal account) to create a temporary RG for restoration, does not include a placeholder to assign a tag, or to create one at random (any tag for the matter), and this is when the restore process failed completely.

Obviously, some of you will argue by saying that why I don't restore to an existing RG and subnet, and then delete (or even overwrite) the existing VM, and then manually move the restored VM to its intended, target home location. The answer is that I don't have the privilege of a contributor role to do so, other than to operate the Veeam's console. My organization had been coached by single-minded, obtuse security minions that everyone must be assigned least-privilege, based on the new security bible verse that advocates "zero-trust": You only get enough role permission to do your job - nothing more is allowed. This draconian approach really hurts progress for engineers like me that wear numerous hats, but sometimes your hands are tied if you don't have a voice in the inner circle of decision-making process.

But even Veeam itself is advocating least-privilege, so I really don't really have much to argue for.

My question for Veeam experts and developers is that: Is it possible to add an option to assign a tag to the temporary RG that the service account will make use, prior to the restore process?

When can Veeam insert a tag-inclusive feature to circumvent this issue?

[nielsengelen]

@DavidAmerica I’ve merged your post with the topic around this. Can you see if any of the above workarounds would work for you?

Either by using the tag assign workaround or to use the “restore to a new location” and select the original region without changing any settings?

[sandsturm]

Hi
How about the status of this "tag" recovery for the temporary RG? We do not allow the creation of resources without having a set of tags and therefore the restores fail for the same reason as explained above in this thread. In which release will this be implemented? As above mentioned, if the same tags of the VM will be restored to the resource group, it will be fine.

thx,
sandsturm

[Vitaliy S.]

There is no specific version planned for that, but we will try to accelerate this feature in our upcoming releases.

[sandsturm]

... but we will try to accelerate this feature in our upcoming releases

thank you, that would be very helpful!
sandsturm