Overview

Upgrading Veeam Backup & Replication from v12 to v13 is usually painless — until the installer hard-stops with this message:

[Error] Outdated Veeam Agents
Please upgrade or remove the following Veeam agents from the product configuration:
OLD-AGENT-HOST (Veeam Agent for Windows 3.0.2.1170)

The problem?
OLD-AGENT-HOST no longer existed anywhere in the environment.

• No backups
• No protection groups
• No inventory objects
• Nothing visible in the UI

And yet the v13 installer refused to proceed.

This post walks through why this happens, why the usual cleanup methods fail, and how to fix it correctly when your Veeam configuration database is running on PostgreSQL.

What’s Actually Going On

Veeam v13 introduced stricter prerequisite checks than v12. One of those checks validates agent inventory state, not just backup jobs or objects.

That inventory data lives in Veeam’s Enterprise Plug-in (EP) tables and can persist even after:

• a machine is decommissioned
• the agent is uninstalled
• the backup object is deleted

Veeam v12 tolerates this inconsistency.
Veeam v13 does not.

There is no “ignore” or “continue anyway” option. The stale record must be removed.

Why the UI and PowerShell Show Nothing

Every obvious place was checked:

• Home → Backups → Agent Backups
• Inventory → Physical Infrastructure
• Protection Groups

Nothing referenced OLD-AGENT-HOST.

PowerShell wasn’t helpful either — even when the Veeam cmdlets are available, these EP inventory records often don’t surface in a way that allows removal.

At this point, the configuration database is the only source of truth.

Safety First

Before touching the database:

• Take a Veeam Configuration Backup
• Preferably stop write-heavy services (at minimum Veeam Backup Service)
• Use transactions so you can safely roll back if needed

BEGIN;
-- changes
COMMIT;
-- or ROLLBACK;

Step 1 — Identify the Blocking Agent Version

The installer helpfully tells you the agent version it’s unhappy with.

Query the EP agent inventory:

SELECT
    host_id,
    bobject_id,
    agent_version,
    is_upgrade_required,
    agent_installation_status
FROM "backup.model.epagents"
WHERE agent_version = '3.0.2.1170'
   OR agent_version ILIKE '3.0.2.%';

Example Result:

host_id	agent_version
<EP_HOST_UUID>	3.0.2.1170

This confirms the installer is blocking on a legacy Agent 3.x record.

Step 2 — Map the Agent Record to a Host

The epagents table does not store hostnames directly. Host details are stored in:

backup.model.ephosts

Inspect the table (optional but recommended):

\d "backup.model.ephosts"

Now retrieve the EP host record:

SELECT
    id,
    connection_point,
    display_name,
    os_version,
    host_state,
    host_aux_data
FROM "backup.model.ephosts"
WHERE id = '<EP_HOST_UUID>'::uuid;

What You’ll See

If this is the ghost entry, fields like these will jump out immediately:

• connection_point: OLD-AGENT-HOST
• display_name: OLD-AGENT-HOST

At this point, you’ve proven exactly what’s blocking the upgrade.

Why Deleting the EP Host Is the Correct Fix

This is the critical relationship:

backup.model.epagents.host_id
  → references backup.model.ephosts(id)
  → ON DELETE CASCADE

Deleting the EP host automatically removes:

• the EP agent inventory record
• EP agent membership rows
• EP agent backup statistics
• related EP metadata

This is the clean, supported way to resolve the condition.

Step 3 — Delete the Orphaned EP Host

Delete the EP host inside a transaction:

BEGIN;

DELETE FROM "backup.model.ephosts"
WHERE id = '<EP_HOST_UUID>'::uuid;

COMMIT;

Verify Cleanup

SELECT *
FROM "backup.model.epagents"
WHERE host_id = '<EP_HOST_UUID>'::uuid;

Expected result:

0 rows

Step 4 — Clear Cached Installer State

After database changes, don’t reuse an already-running installer window.

On the Veeam server, restart the following services:

• Veeam Backup Service
• Veeam Installer Service
• Veeam Broker Service (if present)

Then launch the v13 installer fresh.

The “Outdated Veeam Agents” check should now be gone.

Common Gotchas

PostgreSQL case sensitivity

• Unquoted identifiers fold to lowercase
• Quoted identifiers are case-sensitive

If a table is named bobjects, “BObjects” will not work.

The hostname may not be stored as name

You may need to correlate using:

• connection_point
• display_name
• agent_version
• host_id

Deleting bobjects is not enough

The v13 installer checks EP agent inventory, not just backup objects.

Lessons Learned

1. Veeam v13 validates agent inventory, not just backups
2. Orphaned EP records can block upgrades silently
3. Removing the EP host is the correct cleanup method
4. Restart services to avoid cached prerequisite results

Final Advice

• Always take a configuration backup before DB work
• Delete parent EP host records, not child agent rows
• Trust what the installer tells you — it’s reading real data

This is one of those cases where the UI shows nothing, PowerShell can’t help, and the database is the only place the truth lives.

Being a good netizen, I did a quick websearch for Torii to see if I could dig a bit more into it. Turns out, I got side tracked for a bit of culture. (one of my favorite kinds of distractions!) And now, I’m sharing this with you.

Torii, the SaaS product: https://toriihq.com/platform/

Torii, the traditional gateway : https://en.wikipedia.org/wiki/Torii

You’ve likely seen a real torii before if you’ve viewed photos from Asia – especially Japan, if I understand correctly. I never knew that’s what those structures were named, nor their purpose.

Now I know, and so do you. 😁

I started playing with Chocolatey today. I’m planning to use it to install and update software used by myself and fellow administrators on various Windows servers. The nice thing about it is there’s no “click, click, next, finish” to it. It’s repeatable and reproducible and makes admin life easier.

To top it off, when used in combination with PowerShell you can remotely install software. As an example:

Invoke-Command -ComputerName HOST1,HOST2,HOST3 {
    choco install git.install -y;
    choco install sysinternals -y;
    choco install vscode -y;
    choco install vscode-powershell -y
} -Credential (Get-Credential) -Verbose

I’m just getting started with it and am curious to see how upgrading software works.

Are you using Chocolatey? What are you using it for? I’d be curious to hear from others to learn from you. 😊

Case/issue:

When activating Windows Server 2019 via the GUI and with a MAK key, you receive the following message: “The product key you entered didn’t work. Check the product key and try again, or enter a different one.” (in my case it listed error code 0x80070490 - your error may vary)

How I resolved the issue:

Via Admin-elevated Command Prompt, I entered the following: slmgr /ipk <INSERT-YOUR-MAK-KEY-HERE>

Scratching my head

I’m a bit confused as to why something like this exists in a modern server OS, but hey - at least it’s not a huge roadblock. While I prefer to keep activations with MAK keys to a minimum (and use KMS), in this instance a MAK was necessary. (a non-domain joined host for a specific purpose)

Hope this helps someone today or further into the future.

Today, read through commenting options for Github pages/blogs. I’m leaning towards open source situations - and desiring to keep content (including comments) as close to my virtual home as possible.

The key source of help was this blog article by François-Xavier Cat. (thanks François!)

Utterances will allow for me to keep comments within the blog itself. (Saved as GitHub issues on the blog repo)

A bit more info can be seen at Utterance’s site at: https://utteranc.es/?installation_id=1271653&setup_action=install

Have fun out there!

-=t3hcr=-

I’ll be back with more content as I get this figured out.

Until next time… learn something you can share with those around you. I’ll be doing my part to do this for you and others too!

t3hcr