Skip to main content
Solved

Duplicate Organisation Office ID conflict after migrating to new Veeam M365 backup server

  • February 26, 2026
  • 5 comments
  • 31 views
T

Hi all,

I have recently built a new Veeam Backup for Microsoft 365 server (v8.3.0.2201 P20251212) and attached existing Azure Blob storage from a previous server which contains backup data I need to restore from.

The issue is the Microsoft 365 tenant was previously named [OLD-TENANT-NAME].onmicrosoft.com and has since been renamed to [NEW-TENANT-NAME].onmicrosoft.com. Both entries share the same Office ID ([OFFICE-ID]) which is causing a duplicate conflict and preventing me from accessing the existing restore points.

The error we are seeing is:

A duplicate organization Office ID was found in the repository (Office ID: [OFFICE-ID])

The old tenant no longer exists in Microsoft 365 as it was renamed. The backup data in the blob storage is tied to the old org entry and we need to remap it to the current tenant so we can perform restores.

What we have already tried:

  • Removed the old organisation entry from the Veeam console - did not resolve the conflict
  • Removed and re-added the Azure Blob repository and performed a full re-sync
  • Removed the new organisation and re-added it after the re-sync - duplicate conflict persists
  • Stopped all Veeam services, wiped and rebuilt the Veeam config database, re-added the blob repository and re-added the organisation - same duplicate Office ID error returned

Org details for reference:

  • Old org: [OLD-TENANT-NAME].onmicrosoft.com — Org ID: [OLD-ORG-ID]
  • New org: [NEW-TENANT-NAME].onmicrosoft.com — Org ID: [NEW-ORG-ID]
  • Shared Office ID: [OFFICE-ID]

Has anyone encountered this after a tenant rename and found a way to remap the org in the repository metadata without Veeam support access (licensing was expired last year no active support anymore)? 

Any help appreciated.

Best answer by techenvy

Hi Chris,

Thanks for the suggestion on remapping, that got me thinking and I decided to check if I could manipulate the database directly rather than touching the blob storage.

After querying the PostgreSQL database I found two organisation entries with the same Office Tenant ID. The old org entry had its office_tenant_id set to all zeros which meant Veeam had no way to match it against the blob metadata, and this was causing the duplicate conflict every time the repository synced.

The fix was straightforward once I found this. I updated the old org entry with the correct office_tenant_id, marked the newly added org as deleted, then restarted the Veeam services. After the restart the old organisation appeared in the console and the backup data in the repository was accessible and recoverable.

Hopefully this helps someone else who runs into the same issue after a tenant rename.

    5 comments

    Chris.Childerhose
    Forum|alt.badge.img+21
    • Chris.Childerhose
    • Veeam Legend, Veeam Vanguard
    • February 26, 2026

    Never seen this with all our installs so cannot give suggestions.  You will need support to get this figured out as they will be able to help with database edits if needed to try to remap them.  It is unfortunate that has expired so I would get it renewed and a ticket opened.

    Chris Childerhose (Enterprise Architect) - VMCA2024 | VMCE2023 | VMCE-SP2024 | Veeam Vanguard 8* | Veeam Legend 5* | VUG Canada Leader | vExpert 6* | Toronto VMUG Leader | VCAP-DCV/VCP-DCV | Object First Ace | Cisco Champion | Twitter: @cchilderhose | Blog Site – https://just-virtualization.tech
    T
    • techenvy
    • Author
    • Not a newbie anymore
    • Answer
    • February 26, 2026

    Hi Chris,

    Thanks for the suggestion on remapping, that got me thinking and I decided to check if I could manipulate the database directly rather than touching the blob storage.

    After querying the PostgreSQL database I found two organisation entries with the same Office Tenant ID. The old org entry had its office_tenant_id set to all zeros which meant Veeam had no way to match it against the blob metadata, and this was causing the duplicate conflict every time the repository synced.

    The fix was straightforward once I found this. I updated the old org entry with the correct office_tenant_id, marked the newly added org as deleted, then restarted the Veeam services. After the restart the old organisation appeared in the console and the backup data in the repository was accessible and recoverable.

    Hopefully this helps someone else who runs into the same issue after a tenant rename.

      Chris.Childerhose
      Forum|alt.badge.img+21
      • Chris.Childerhose
      • Veeam Legend, Veeam Vanguard
      • February 26, 2026

      Great to hear that I am not one to play with the DB but wish I did know more about them 😜 

      Chris Childerhose (Enterprise Architect) - VMCA2024 | VMCE2023 | VMCE-SP2024 | Veeam Vanguard 8* | Veeam Legend 5* | VUG Canada Leader | vExpert 6* | Toronto VMUG Leader | VCAP-DCV/VCP-DCV | Object First Ace | Cisco Champion | Twitter: @cchilderhose | Blog Site – https://just-virtualization.tech
      coolsport00
      Forum|alt.badge.img+21
      • coolsport00
      • Veeam Legend
      • February 26, 2026

      Interesting find ​@techenvy ! Thanks for sharing your solution...no doubt this will help someone at some point.

      Shane Williford - Veeam VMCA/VMCE | Veeam Legend | VUG Leader | VCP-DCV | Twitter: @coolsport00
      kciolek
      Forum|alt.badge.img
      • kciolek
      • Comes here often
      • February 27, 2026

      Never experienced an issue like this. Thank you for sharing the solution!

      Ken Ciolek | Team Lead, Data Protection & Storage | Object First Ace |
      Terms & ConditionsAccessibility statement