How do we move agent to associate with a new Veeam Server?

[CaliMSP]

Just made a new deployment of Veeam 11a. Have workstations that are associated with the old v9.5, which is being decommissioned. When Veeam 11a rescan the workstations - it says "Failed to acquire agent managed by OLD_SERVER".

Is there a way to release them from the old server and be accepted by the new so that we don't need to remote into each workstation?

[Dima P.]

Hello CaliMSP,

What agent version is installed on the client side? Thanks!

[CaliMSP]

3.0.2.1170

[Dima P.]

Thank you! You can use registry key with pre-v12 B&R versions

Code: Select all

HKEY_LOCAL_MACHINE\SOFTWARE\Veeam\Veeam Backup and Replication
AgentDiscoveryIgnoreOwnership DWORD=1

set on your Veeam B&R server v11a. That will force Veeam B&R to acquire agents managed by another Veeam B&R server. After adding this key please make sure that everything works as expected by adding one particular agent to a v11a protection group first. Let us know how it goes!

For v12 please use key mentioned in this post.

[chalkynz]

Hi, that sounds useful, can you be more specific about this registry entry? Which part of the registry does it go in? Is it a key or a value? If it's a value what type, and data do I set it to? Thanks!

[Dima P.]

Hello Nathan,

Sure, you need to add key with the name AgentDiscoveryIgnoreOwnership to the machine where you B&R is installed; the path to the key is HKEY_LOCAL_MACHINE\SOFTWARE\Veeam\Veeam Backup and Replication and value is not required, we basically check the existence on the key to ignore agent lock created by another B&R installation.

[tim.maier]

Having the same issue with VBR 11.0.1.1261 P20220302 and Agent 4.0.1.2169. Added a REG_SZ entry with no data under "HKEY_LOCAL_MACHINE\SOFTWARE\Veeam\Veeam Backup and Replication". After reboot of VBR server the entry is renamed to "INVALID_OPTION_AgentDiscoveryIgnoreOwnership". Rescan failes with "Failed to acquire agent managed by OLD_SERVER". Any hints what I'm doing wrong?

[Dima P.]

Hello Tim,

UPDATE: The REG_DWORD type is required, so that's why registry entity got renamed. It seems that starting from v11 B&R can actually validate registry entries and add INVALID_OPTION_ prefix whenever some value is not correct in it's own hive. Hope this helps!

[tim.maier]

Hello Dima,

I just added the REG_DWORD key with the value = 1.
Works flawlessly. Thanks for the update and support!

[Dima P.]

Glad you nailed it Tim! Big thank you for the feedback and sorry for the minor confusion, I've added the exact value type to my previous post to make it crystal clear for the newcomers

[simone77ms]

We moved succesfully agent from old server to the new one.
Does anybody know if is possible to import also the old backup chains from the old server agent repo?

[micoolpaul]

Hi Simone, if the repository is added to the new VBR server I can't see why it wouldn't be able to, though you shouldn't have the repo attached to two VBR instances at the same time (at least mapped to the same folder), so just be mindful if the old VBR server is still around.

[simone77ms]

Hi Michael,
we moved the (agent)repo from the old server to the new one, we scanned it, B&R found the old backups and marked them as "imported". After we re-created the agent jobs on the new server but in the -repo selection window- there is no "map backup" link.
So the agents, during the next bck cycle, start a new backup chain, no matter about the imported repo with previous backups...

[micoolpaul]

Thanks for the update, in which case you'd need to raise a case with Veeam support to understand if there are any supported pathways for you.

[simone77ms]

Hello,
this is the answer from Veeam support:
reference link https://helpcenter.veeam.com/docs/backu ... ml?ver=110
where you can find "You cannot map a backup policy to another Veeam Backup & Replication server"

At last this is the official answer "[...] if you are migration from an old Backup and Replication server to a new one you won't be able to actually map the backup files to the old backup chain."
So actually, it seems you can import the old backups from the migrated repo, but you can't map them to the new policies. So new backup chains are created on the next scheduled agent backup.

Hope I have understood it correctly...

[DaStivi]

looks like this doesn't work anymore in Veeam V12
set the reg-dword key but vbr still complains about agent is managed by another vbr server...

[kyle.shuberg]

@DaSitivi Did you go through this process to recreate the configuration database? I just went through this as well upgrading to v12 https://www.veeam.com/kb2335 did the trick for me

[Dima P.]

Hi Stephan,

Can you please share a support case with us? Thank you!

[Dima P.]

Folks,

Quick update: since v12 now can deploy not only agents but application plug-ins as well the old key was replaced by the new one and now it can be used to 'acquire' not only the locked agent but locked machine with backup plug-in too.

For v12 installations whenever it's need to address the issue, please use this key instead. Thank you and sorry for the confusion:

Code: Select all

HKEY_LOCAL_MACHINE\SOFTWARE\Veeam\Veeam Backup and Replication
ProtectionGroupIgnoreOwnership DWORD=1

[panzer]

I need to move a Linux backupjob to a new server. All backupfiles have been copied to my new repository. It looks like adding the new Linux host under Backup Infrastructure - Managed Servers is OK, but when I rescan under Inventory I get: Skipping <HOSTNAME> Details: This backup agent is managed by the Backup server <Old backup server>, ignoring control request from <New backup server>

[HannesK]

Hello,
please see above.

Best regards,
Hannes