Skip to main content
  • EN

UPDATE--  Check out the step by step in our helpcenter 

https://helpcenter.veeam.com/docs/backup/vsphere/using_vm_migrator_utility.html?ver=120

 

12.3 What’s New - https://www.veeam.com/veeam_backup_12_3_whats_new_wn.pdf

HelpCenter - https://helpcenter.veeam.com/docs/backup/powershell/veeam_vm_migrator.html?ver=120

 

 

Hey Everyone,

 

What is a Moref ID?

 

In VMware, a Moref ID (Managed Object Reference ID) is a unique identifier assigned to different objects or resources within the vSphere environment, like virtual machines, hosts, or data stores. It helps VMware keep track of and manage these objects.

Think of it like a name tag that VMware uses to identify and reference each specific object in its system.

 

The MoRef ID naming starts with a prefix stating the object type followed by a hyphen and a number, for example, vm-197, host-29, domain-c26. Every object has its own MoRef address: https://<VCENTER>/mob/?moid=<OBJECTID>.

 

 

So why is it Important?

 

When a virtual machine (VM) is added to a job in Veeam Backup & Replication (VBR), that VM's vSphere-assigned Managed Object Reference ID (MORef ID) is recorded within the VBR configuration database. In addition to the VM's MORef-ID, the BIOS UUID of the VM is recorded in the database as a secondary reference point for identifying the machine. VBR then uses the MORef ID to refer to the VM when interacting with the vSphere environment. This ensures that VBR always interacts with the correct VM, and tasks are unaffected should the VM's name be changed.

 

When a vCenter (VC or VCSA) is either rebuilt with a new database or a new VC is built and old resources are migrated, that vSphere environment will assign the VMs new MORef-IDs. This change in MORef-ID causes the entries within the VBR configuration database to become invalid. This, in turn, causes VBR to be unable to make requests to interact with and protect those VMs because the MORef-IDs it would attempt to reference when communicating with the VC have become invalid.

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?

 

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.

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

 

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.

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

I didn’t test it yet, did you? 

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.

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.

Comment


Terms & Conditions