Unable to Remove Orphaned VHR Repository v2 from VBR v13

In this article, we shall discuss the steps to fix “Unable to Remove Orphaned VHR Repository v2 from VBR v13”. As system administrators, we believe everything is possible, provided you think it through. Therefore, I will proceed and show you the steps to fix this. Please, see How to set up Veeam Software Appliance v13, how to deploy and integrate VHR with VBR, and how to Upgrade Veeam Backup and Replication v12.3 to v13 on Windows.

Yes, this task was no longer straightforward, as the usual workflow for deleting or removing backup jobs tied to the repository, and for deleting the repository itself when it is no longer needed, before removing the managed server. This was due to the use of single-use credentials.

Please, see how to Upgrade Path and In-Place Upgrade for VBR v13 and Known Fixes, and “the Best Storage for Veeam: Comparing OOTBI by ObjectFirst to VHR.

Reproducing the Error “Root User Cannot be Accepted for Single-Use Credential”

What happens when you no longer have the VHR v2 Server due to the reinstallation of VIHR? To reproduce this error, we will launch the VBR console as shown below.

Note: The root issue here is that the transport service continues to run under the context of the veeamsvc. This means that the account must remain present on the Linux server. Please, see how to deploy and integrate VHR with VBR. Veeam only requires the credentials during the initial deployment of the transport service.

This is why single-use credentials are used. But as we see, due to updates and upgrades. We have to regenerate the single-use credential as discussed here “Veeam Host Components: Unable to reinstall Deploy Service SSH“. This method was used effectively to upgrade the component. But now, I have reinstalled the Repo and we have to find a way around this issue.

When we try to remove it, we are prompted with the error below. Removing Veeam components requires credentials with root privileges. Specify credentials now.

Assume Connection to VHR

Also, because this (infrastructure) environment has been removed. You cannot also connect to it with any other root credential, as the transport service continues to run under the context of the veeamsvc (single-use credential). Here is a similar error discussed; perhaps these solutions might better suit you.

To demonstrate this, navigate to the backup infrastructure, and as you can see. When we wish to connect via SSH or a certificate-based authentication method. It will not work

Click Yes to trust the server. It will fail very shortly.

When you try to use SSH with any root credentials. We already know that this will fail.

Please, see how to create a bootable USB on Mac: Proxmox VE Setup. Also, see how to generate CSR and request a Certificate from Herica CA.

Remove the deleted VHR v2 from VBR

To remove the deleted VHR server (likely “VHR”) from Veeam Backup & Replication (VBR) v13 managed servers after the job and repo are gone. Please, use PowerShell as shown below since the Web UI cannot be used in this case.

Kindly run the command on the VBR server. This unassigns the repo role only. The VHR server stays in managed servers if added separately; data on the Linux host remains untouched. But, this is not what I want as the server stays and repo vanishes which I have done before.

Get-VBRBackupRepository -Name "192.168.2.78" | Remove-VBRBackupRepository -Confirm:$false

To completely remove the VHR repo (“192.168.2.78”) from VBR v13. Unassigning it, and clearing all references, and handling the deleted host. Run the below PowerShell command.

Get-VBRServer -Name "VHR IP address or FQDN" | Remove-VBRServer -Confirm:$false

Ignore the final unreachable host warning that the server throws from the managed servers

Why was the error “Failed to open deployer service management port”

The “Failed to deploy management agent port” error was prompted because. The VBR server was unable to conenct the deleted VHR host (192.168.2.78) on port 6160 for the Veeam Installer Service. I will show you in a different blogpost how a similar error was fixed.

Now, lets now force the server removal despite the agent deploy failure. Run the below command.

Get-VBRServer | Where-Object {$_.Name -like "*192.168.2.78*"} | Remove-VBRServer

Then run the commands below to verify. Both should return nothing as shown below.

Get-VBRBackupRepository | Where-Object {$_.Name -like "*192.168.2.78*"}
Get-VBRServer | Where-Object {$_.Name -like "*192.168.2.78*"}

You can also use the commands below to confirm that the repo and server were correctly removed.

Get-VBRBackupRepository -Name "192.168.2.78"
Get-VBRServer | ? Name -like "*192.168.2.78*"

Please, see What Ransomware Recovery looks like when the clock is ticking, and how to set up Devolusion Remote Desktop Manager on Windows. Also, see Hardening Your Infrastructure: A Guide to VMware VBS and MS GPO Credential Guard in VBR v13.

Add a Managed Server to VBR v13

To add a new server, navigate to the Backup Infrastructure and select Managed Server. You can right-click on the working area or the ribbon to select “Add Server”.

Click on Linux

Note: FQDN works reliably in VBR/VSA v13 due to strict reverse DNS requirements for certificate authentication, SSH, and agent deployment on Linux. IPs skip PTR lookups and often fail validation.

Because of this, launch DNS Manager and create an A Record as shown below for the new VIHR server.

In the new Linux Server window, enter the FQDN and click Next

Select the Connect using Certificate-Based Authentication method

As you can see, it is connecting to the installer service

Shortly, you are prompted to trust this server. Click on Yes to do so.

Note: You can also do all these via the Web UI, as shown below. This is the game changer introduced in v13. The ability to manage VBR over the web.

As you can see below. The following will be installed on the target host.

Here is a summary of the new VHR we have added.

That is all you needed to do to remove and add a new Linux Hardened Server to VBR.

I hope you found this article on how to fix “Unable to Remove Orphaned VHR Repository v2 from VBR v13” very useful. Please, feel free to leave a comment below.