VBO PowerShell Error - Stale Proxy GUID Causes Get-VBORepository Failure (Case #07986991)

[t7MevELx0]

Hello R&D Team,

I am posting for additional visibility regarding Veeam Support Case #07986991.

Product
Veeam Backup for Microsoft 365

Issue
When running the following script:

Code: Select all

Get-VBORepository | ForEach-Object {
[PSCustomObject]@{
Name         = $.Name
ServicePoint = $.ObjectStorageRepository.Folder.Bucket.ConnectionSettings.ServicePoint
}
} | Format-Table -AutoSize

We receive:

Code: Select all

Proxy does not exist: 47ecb35e-de57-47eb-8576-4dd4ac01434c

Current State of the Environment

Code: Select all

Get-VBOProxy -Id 47ecb35e-de57-47eb-8576-4dd4ac01434c

Returns: Get-VBOProxy: Proxy does not exist.

- Repositories previously associated with that proxy are now configured to use a proxy pool.
- Backup jobs are running successfully.
- The only failure occurs during Get-VBORepository.
- If we open each repository in the UI and click Next → Next → Finish, the PowerShell error disappears for that repository.

Important Behavior
This appears to indicate that:
- A stale proxy GUID reference is retained in repository configuration.
- The stale reference is not automatically reconciled when a proxy is removed or repositories are re-bound to a proxy pool.
- The UI refresh forces the configuration to re-save and clears the issue.
- There is no supported bulk method to reconcile or rebind repositories.

Support Interaction So Far
- Multiple full log bundles and targeted PowerShell logs have been provided.
- Commands requested by Support have been executed and results shared.
- Support is currently investigating whether the proxy ever existed.

Product Behavior Perspective
- If the proxy existed and was removed, configuration cleanup did not fully reconcile references.
- If the proxy never existed, an invalid GUID reference was created internally.
- In both cases, a stale configuration reference remains and breaks PowerShell enumeration.

Scale Impact
This environment contains 300+ repositories. Manually opening and re-saving each repository is not operationally viable in a service provider environment. We rely heavily on PowerShell automation; having enumeration fail due to stale internal references significantly impacts automation at scale.

Questions for R&D
- Is this a known issue in VBO?
- Is there a supported bulk method or remediation script to clean stale proxy GUID bindings?
- Should proxy removal automatically rebind repositories without leaving residual GUID references?
- Is R&D involvement already expected under Case #07986991?

Thank you.

[Bjoern_ch]

Hi,
recently had the very same issue. For us, support solved it very efficiently.
Thanks for sharing here. With your post it could have been solved even faster I guess.

After removing the "missing proxies" from the db it is working fine. We identified the repos which are missing the proxy (or have a stale proxy) via pgadmin:
SELECT * FROM public.repositories
Where proxy_id='YOUR_PROXY_ID '
ORDER BY proxy_id ASC

We have a lot of repos as well but only in a few a "missing proxy" was present. So, there was no need to click through all repos.

[t7MevELx0]

Hi @Bjoern_ch ,

Thank you for this - this is extremely helpful.

I ran the query against our PostgreSQL backend.

We have identified 112 repositories with this stale proxy reference. This aligns exactly with the behavior we are seeing:

- Proxy no longer exists.
- Repositories are bound to a proxy pool.
- PowerShell fails until each repo is opened and re-saved.

This confirms the issue is a stale proxy_id reference retained in the database.

Question for R&D:
- Is there an official remediation script or supported cleanup procedure that Support can provide?

Case #07986991 is currently open with Support. Appreciate the confirmation and direction.

[track1044]

Go "next next" on all the repos that still exists fixed it for us and correctly assigned a new proxy.

Regarding automation powershell won't work, but the API still worked for us.