I have an existing case 08028917
Root issue is on the daily, the worker fails to synchronize update options, causing a perpetual update settings sync item in the Failed folder on the Home panel.
1. User defined password for the worker, at the time of worker deployment. The worker is deployed with a password that only VBR and the worker care about. However, we as admins don't know what that password is, or how to (operative phrase) easily take control of it. Case engineer did provide a round-about procedure to change the password. Not exactly an exact process, not the support engineer's fault.
Password creation or password modification must be native to the worker deployment / post deploy management, because worker is a node on the network, and we gotta have access control over it. I don't know yet what manner of fresh hell auditors have for us if we are backing up SOX / CUI / SPA servers with the worker, but admin access to the worker can be audited.
2. Worker powers off after backup, but does not have a native option to keep it powered on. Case engineer provided a procedure to change a .json parameter. This need to be a radio button option at the time of worker deploymnet, e.g keep powered on after backups complete. Also selectable in Properties post-install. Our Esseentials is on prem, and is not subject to any internal chargeback for utilization, so I see no pressure to power it off.
3. Unable to natively schedule of worker power on X minutes prior to scheduled backup. If I choose to keep the worker powered off, I would like it to power on, say, 10 minutes prior to backups. Veeam should do this natively, I should not have to write a script for HPE to power on the VM.
Further, I don't know how the worker "knows" how many jobs it is scheduled to do. To have the worker power on, power off, power on, power off as driven by the job schedules feels like a whole bunch of power actions that just don't have to happen.
4. Properties of the worker is grayed out, when worker is powered on. The only option available is Disable Worker. Why? Properites should always be active, regardless of worker power state. Seems like a bug, or an incorrect decision on the part of developers.
-
sdolcourt
- Influencer
- Posts: 20
- Liked: 30 times
- Joined: Oct 22, 2025 7:17 pm
- Full Name: Seth Dolcourt
- Contact:
-
cody.ault
- Veeam Software
- Posts: 134
- Liked: 61 times
- Joined: Nov 04, 2010 2:53 pm
- Full Name: Cody Ault
- Contact:
Re: Feature Reqeusts - HPE Essentials worker
Hey Seth, I'll discuss your feedback internally with the team.
Regarding #1. In general, the workers for our platform service integrations are intended to work as an appliance and access to it is restricted out of the box to minimize the attack surface and prevent issues with someone manually making changes or installing things on the box that might make it out of sync with VBR or some malicious software by mistake. Can you provide some info on what kind of operations you would like to do once logged into the worker (collect logging/setup syslog to a collector/something else)?
Regarding #1. In general, the workers for our platform service integrations are intended to work as an appliance and access to it is restricted out of the box to minimize the attack surface and prevent issues with someone manually making changes or installing things on the box that might make it out of sync with VBR or some malicious software by mistake. Can you provide some info on what kind of operations you would like to do once logged into the worker (collect logging/setup syslog to a collector/something else)?
-
sdolcourt
- Influencer
- Posts: 20
- Liked: 30 times
- Joined: Oct 22, 2025 7:17 pm
- Full Name: Seth Dolcourt
- Contact:
Re: Feature Reqeusts - HPE Essentials worker
Hi, Cody,
No idea what can or should be done on the worker, from a functional level. I view the HPE worker no differently than the Veeam infrastructure appliance product. VIA gets a console and a nifty host management interface, offering a modecum of access to manage a small assortment of function.
If the HPE worker offered a console capable of setting root password, disabling updates, enable / disable power off after backups complete, that might be good enough to say we have planted a corprate flag in it.
Our general IT polices are written that any device connected to the corporate network needs to play with the corprate rules. Our security department executes sweeps on a regular basis, perhaps they might try to brute-force against the worker's password. Possibly we'd have to create security exception paperwork, stating we have no means to install security software, e.g. anti-virus, threat prevention, SCAP scans, etc.
We have no requirement to install an NCPA agent that can monitor services or disk space.
I don't know what auditors might have for the worker that is passing SOX / CUI / SPA data. Auditors typically have nothing better to do all day long, than ask inane questions like "Can you get me a list of everyone who has access to this device?" and "Why don't you have access to this device?"
No idea what can or should be done on the worker, from a functional level. I view the HPE worker no differently than the Veeam infrastructure appliance product. VIA gets a console and a nifty host management interface, offering a modecum of access to manage a small assortment of function.
If the HPE worker offered a console capable of setting root password, disabling updates, enable / disable power off after backups complete, that might be good enough to say we have planted a corprate flag in it.
Our general IT polices are written that any device connected to the corporate network needs to play with the corprate rules. Our security department executes sweeps on a regular basis, perhaps they might try to brute-force against the worker's password. Possibly we'd have to create security exception paperwork, stating we have no means to install security software, e.g. anti-virus, threat prevention, SCAP scans, etc.
We have no requirement to install an NCPA agent that can monitor services or disk space.
I don't know what auditors might have for the worker that is passing SOX / CUI / SPA data. Auditors typically have nothing better to do all day long, than ask inane questions like "Can you get me a list of everyone who has access to this device?" and "Why don't you have access to this device?"
Who is online
Users browsing this forum: No registered users and 1 guest