Skip to main content

Veeam Moref ID Migration Tool - Updated 12.2

  • September 24, 2024
  • 34 comments
  • 3751 views

Show first post

34 comments

  • New Here
  • January 2, 2025

It would be great if the previous, “unsupported”, tool that worked with 12.2 was still available for those of us that cannot yet upgrade to 12.3 due to change control (or other business-related) requirements.

If 12.2 hasn’t reached the end of it’s support lifecycle (Feb. 1, 2026), why remove availability to tools that work with it?

 


  • New Here
  • March 6, 2025

As I understand it, this tool is for migrating vSphere VM MoRef’s and UUID’s between old and new vCenters, thus preserving the existing backup job chain for VM’s (and thus avoiding orphaned backup chains, the expiry for which is no longer managed and ends up taking up necessary repository storage).

We often encounter situations, for example in a full platform reboot, where we have to remove an orphaned VM from the existing vCenter Inventory and then add it back again. This causes it to generate a new MoRef and in turn, orphans the VM from its existing backup chain.

There used to be an unsupported mechanism for mapping old and new MoRef ID’s if you were using Veeam with MS SQL Server. However, recently, we have had to move to PostgreSQL as the 10GB SQL Express limit was reached.

Is there any sort of similar mechanism or tool available for mapping changed MoRef ID’s in the same vCenter when using Veeam with PostgreSQL?

 

Thanks.


AndrePulia
Forum|alt.badge.img+9
  • Veeam Vanguard
  • March 6, 2025

As I understand it, this tool is for migrating vSphere VM MoRef’s and UUID’s between old and new vCenters, thus preserving the existing backup job chain for VM’s (and thus avoiding orphaned backup chains, the expiry for which is no longer managed and ends up taking up necessary repository storage).

We often encounter situations, for example in a full platform reboot, where we have to remove an orphaned VM from the existing vCenter Inventory and then add it back again. This causes it to generate a new MoRef and in turn, orphans the VM from its existing backup chain.

There used to be an unsupported mechanism for mapping old and new MoRef ID’s if you were using Veeam with MS SQL Server. However, recently, we have had to move to PostgreSQL as the 10GB SQL Express limit was reached.

Is there any sort of similar mechanism or tool available for mapping changed MoRef ID’s in the same vCenter when using Veeam with PostgreSQL?

 

Thanks.

HI, Ragnar posted an alternative way to migrate, have a look at https://helpcenter.veeam.com/docs/backup/powershell/veeam_vm_migrator.html?ver=120

 


  • New Here
  • March 6, 2025

Hi - that link is for the new PowerShell VM Migrator for v12.3 which is intended for migrating between vCenters, not for fixing incorrect MoRef ID’s within the same vCenter. As far as I can tell, there is no way to use the new PS tools to remap MoRef ID’s on the same vCenter. - unfortunately.

 

Thanks.


AndrePulia
Forum|alt.badge.img+9
  • Veeam Vanguard
  • March 6, 2025

Hi - But the description says that you can fix it after migration or recreation.

I didn’t test it yet, did you? 


  • New Here
  • March 6, 2025

Hi - we haven’t migrated - this is where you have VM’s that become orphaned within the same vCenter and have to be re-added back, which changes the MoRef ID and breaks the relationship with the Veeam backup. The PowerShell expects a source and target vCenter - that’s not my situation here unfortunately.


Chris.Childerhose
Forum|alt.badge.img+21
  • Veeam Legend, Veeam Vanguard
  • March 6, 2025

Hi - we haven’t migrated - this is where you have VM’s that become orphaned within the same vCenter and have to be re-added back, which changes the MoRef ID and breaks the relationship with the Veeam backup. The PowerShell expects a source and target vCenter - that’s not my situation here unfortunately.

Yeah when this breaks you pretty much have no choice but adding the VM to the job again or starting a new one. You definitely need the old reference for PS to work.


  • New Here
  • July 4, 2025

It’s bad that the oldVcenter must be known as with the previous version of the tool (before using it in powershell) with MSsql there was a chance to create the file without having the old VCenter connected and also make use of it if only one VM had to be reregistered (within the same VCenter). It’s pretty bad to create a new full backup if you have a really large VM instead of mapping to the existing chain by changing the MOref in the DB.

 


Chris.Childerhose
Forum|alt.badge.img+21

It’s bad that the oldVcenter must be known as with the previous version of the tool (before using it in powershell) with MSsql there was a chance to create the file without having the old VCenter connected and also make use of it if only one VM had to be reregistered (within the same VCenter). It’s pretty bad to create a new full backup if you have a really large VM instead of mapping to the existing chain by changing the MOref in the DB.

 

That is why you need to plan this piece carefully and run the PS script before the old VC is powered off.