Agent-based backup of Windows, Linux, Max, AIX and Solaris machines.
Post Reply
skaixa
Novice
Posts: 3
Liked: 1 time
Joined: Nov 20, 2025 6:38 pm
Full Name: PS
Contact:

Feature Request: per-computer Notes field for protected computers, exposed in the job report

Post by skaixa »

Hi all,

I am reopening a request I made in this forum a while back, this time properly
written. My original post was too vague to be actionable and I think that is why
it went nowhere:

forums.veeam.com/viewtopic.php?f=49&t=101100

Feel free to close or merge that one, this post replaces it. I am also linking
two older threads from other users asking for essentially the same thing, because
I do not think this is a one-off need:

forums.veeam.com/viewtopic.php?f=49&t=59350
An alias field for agent computers, so the poster could stop maintaining an
external list mapping machine names to the people using them. The answer at the
time was that it had been noted as a feature request. That was 2019.

forums.veeam.com/viewtopic.php?f=2&t=76126
Notes on VeeamZIP backups, with the argument that after a while the machine name
is the only identifier left and nobody remembers what the backup was for. Same
underlying problem, different object.

Three requests, several years apart, all circling the same gap: there is nowhere
to write down what a machine actually is.

## What I am asking for

A free-text Notes field on the individual protected computer object under
Inventory > Physical Infrastructure.

To be explicit about something my first post got wrong: protection groups already
have a Description field. I am not asking for that again. I am asking for the
equivalent one level down, on the machine itself.

Three things that would make it usable rather than just present:

Show it as an optional column in the Inventory, in both the Windows console and
the new v13 web UI. Put it next to the object name in the job email notification,
because that email is where the identification problem actually bites. And let me
write it through PowerShell and the v13 REST API agent management endpoints,
because I am not typing 400 of these by hand and keeping them current.

Ideally it survives protection group rescan, agent reinstall and re-discovery,
and is included in configuration backup.

## Why the hostname is not enough for us

Environment: VBR 13.0.2, agent management with Windows and Linux agents, 400
protected computers across 20 protection groups. I went through the v13 and 13.1
What's New looking specifically for this and could not find it.

We are a biotech research institute. Most of our protected machines are not
office PCs, they are the data acquisition workstations bolted to laboratory
instruments: chromatography systems, mass spectrometers, plate readers, confocal
microscopes, sequencers. The vendor ships the instrument with the PC already
imaged, and with a hostname the vendor chose. Sometimes COMPUTER245, sometimes
PC-01, sometimes just ACQUISITION. We receive several instruments a year with
names that collide with something we already have.

We cannot rename them. Renaming the acquisition PC breaks the instrument control
software or its licence binding, the vendor engineer will not support the machine
afterwards, and for our regulated workflows it invalidates the qualification of
the system. Many of these machines are also deliberately kept off the domain, in
an isolated VLAN, because the OS image has to stay frozen. So there is not even
an AD object I could annotate instead.

What that looks like in practice: the morning report says "COMPUTER245 - Failed".
Nobody on the team knows which instrument that is, which building, which floor,
or who to call. Somebody opens a spreadsheet, finds the row, and only then can we
act. That spreadsheet is now the most fragile part of our incident response for
instrument backups, and it drifts every time an instrument is moved or a vendor
engineer re-images a PC without telling us. At 400 machines that stopped being an
inconvenience and became a process risk I have to report on.

What I would want stored on each machine:

AKTA Pure 150 - Protein Purification - Bldg B, Lab 2.14 - owner J. Silva
Waters Xevo TQ-S - Mass Spec - Bldg A, Lab 0.03 - GxP relevant - RTO 4h
Tecan Infinite M200 - Plate Reader - Bldg B, Lab 1.07 - isolated VLAN
Illumina NextSeq 550 - Sequencing Core - Bldg C - vendor image, do not patch
Beckman CytoFLEX - Flow Cytometry - Bldg B, Lab 1.12 - decommission Q4 2026

## On protection groups, since that is the obvious answer

I looked at that first. Description and Location are both group level, and my
colliding machines sit inside the same groups. Our 20 groups are already
organised around discovery and deployment behaviour: domain-joined versus
isolated VLAN, Windows versus Linux, reboot-tolerant versus not. Using them to
encode identity would mean roughly one group per machine, so about 400 groups,
with all the rescan, deployment policy and job configuration overhead that
implies. Location has the same limitation, and we already use it for what it was
designed for.

## A smaller version I would take today

If a per-object field is too much for a maintenance release, either of these
would already help:

Include the protection group Description next to each object in the job email
notification. Allow more than one custom column in the Inventory view, so I could
at least surface something.

Happy to send anonymised inventory screenshots to show how bad the name
collisions get, and glad to test an early build.

Thanks for reading,
Skaixa a.k.a Pedro Silva | SysAdmin
Post Reply

Who is online

Users browsing this forum: No registered users and 21 guests