Feature Request: Select Components to Install/Upgrade

[Mildur]

Hi Mark

I moved your request to this topic. Please see my answer from this morning.

Best,
Fabian

[m.novelli]

We have veeam deployed at 10 remote sites in the middle of no where. They are all 5-10mbps network connections (wireless)

All are running 12.3 and take at least 4 plus hours most part to get that update deployed and we have to deploy iso in middle of night otherwise users complain.

A v13 21gb iso is a show stopper because its going to take absolutely forever, and its probably going to crap out at least once or more trying to copy that big of a file (they are wireless after all)
The best part..we need exactly zero of the plug-ins for these sites

With Google Chrome generally the download fail and restart 2 / 3 times due to HUGE size of the ISO

Marco

[donkeymagic]

+1 we should be able to select the features we need and if we suddenly need them be able to install them easily from a repo rather than needing the ISO again. I agree with all the comments of it getting far too big and taking far too long to patch systems with the new requirements.

[Spex]

What's the problem with this change that so many users want?
Veeam is constantly adding new features to the product, but for months they haven't managed to write an installer that allows product selection.
The product itself is already modular and allows the uninstallation of unnecessary components.
I really don't understand it...

[david.domask]

Hi Oliver and Stefan,

Please see Fabian's (mildur) post here, we are working on it.

[JonahM]

I spent some time breaking down the contents of the VBR 13.1.0.411 ISO to see where the space is actually going. There appears to be a significant opportunity here to address both the component-selection request and the increasingly large installer.

At a high level, I found approximately:

• Backup: 2.24 GB
• Catalog: 181 MB
• EnterpriseManager: 545 MB
• Explorers: 265 MB
• Packages: 4.39 GB
• Plugins: 6.27 GB
• Redistr: 1.19 GB
• Setup: 829 MB
• Tools: 2.24 GB

I came up with a few potential ideas while going through the ISO:

Component selection
I think administrators should be able to choose which optional components are installed, including:

• AWS
• Azure
• Entra ID
• KVM
• AHV
• PVE
• Xen
• Kubernetes
• Cloud Director
• SAP
• Oracle
• IBM DB2
• etc.

The same should apply to the various Explorers. If I'm not using Oracle, Exchange, SharePoint, MongoDB, SAP HANA, etc., I shouldn't need to install those components.

Most importantly, the component selection should be persistent across upgrades. If I intentionally remove a component because I don't use it, the next upgrade shouldn't silently reinstall it.

Enterprise Manager
Enterprise Manager seems like an especially good candidate for being completely independent of the VBR installation.

At minimum, it should be optional during VBR installation. Even better would be having a separate Enterprise Manager installer/ISO so environments that use EM can deploy it independently without carrying the entire VBR installation in the ISO with it.

Packages / redistributables
There also seem to be some opportunities to clean up the contents of Packages.

For example, .NET Hosting and EdgeWebView installers appear to be present in both Packages and Redistr. Is there a reason they are included in both locations?

I also noticed installers for both .NET Framework 4.8 and 4.7.2. Are both actually required by VBR? If 4.7.2 is only there for a legacy dependency, can that dependency be identified and potentially eliminated so the older installer doesn't need to be shipped?

IRIS and MongoDB also caught my attention.[/b] They appear to be under Packages. I think they would fit better in Plugins.

Online vs. offline installer
I'd like to see two deployment models:

• Offline installer: contains everything required for an isolated environment.
• Online installer: contains the core installer and downloads only the components selected by the administrator.

Another option would be a repository/custom ISO mechanism where I select the components I need and Veeam generates/downloads an installer containing only those components.

The online installer could also potentially retrieve the latest supported versions of prerequisites such as .NET, PostgreSQL, and other dependencies rather than embedding potentially outdated copies in every installer. That would make addressing CVEs in those dependencies much easier.

Longer term
There are also some interesting opportunities around further modularization. VBR already has UHAPI, so I'd be interested in seeing whether vSphere/Hyper-V functionality could eventually be treated more like plugins rather than being tightly coupled to the core installation.

[m.novelli]

Super appreciated your work JonahM! I agree 100%

How is even possible for a Software Company to produce a 20 GB ISO to install a backup software?

Marco

[Nas]

Hi there,

Can the following components (and more of them) be made optional as well?
Our environment dont even have Dell Data Domain or HPE StoreOnce, so would appreciate if we can choose to skip them from being installed.

Hardware info:
Chassis type: Virtual (Hyper-V)
Cores count: 4
Components:
Dell Data Domain Library
Guest Interaction Proxy using port 6190
HPE StoreOnce Library
Installer service using port 6160
Mount service using port 6170
Veeam Backup VSS Integration using port 6210
Veeam Data Mover service using port 6162
Veeam Standby service
Veeam Threat Hunter
Veeam VSS Hardware Snapshot Provider
VMware VDDK
vPower NFS using port 6161

[Mildur]

Hi @JonahM,

Thanks for the list. We are already tracking several duplicate items and improvement opportunities for the ISO image, and I have shared your comments with the team as additional input.

For everyone: please note that we will not be able to fully refactor the ISO image and installation process in small patch releases such as 0.0.x.x. Work of this scope would likely need to be planned for a major or minor release.

Please keep the feedback coming — we appreciate every comment.

Best,
Fabian

[GT-Engineer]

I spent some time breaking down the contents of the VBR 13.1.0.411 ISO to see where the space is actually going. There appears to be a significant opportunity here to address both the component-selection request and the increasingly large installer.

At a high level, I found approximately:

• Backup: 2.24 GB
• Catalog: 181 MB
• EnterpriseManager: 545 MB
• Explorers: 265 MB
• Packages: 4.39 GB
• Plugins: 6.27 GB
• Redistr: 1.19 GB
• Setup: 829 MB
• Tools: 2.24 GB

Thanks so much for the work. This has been a big sore point for my team. We are a MSP, so this affects us 200 times over and drives us crazy.

[msbreez12]

This is honestly very well written.

This is one of my concerns with Veeam as well. In some cases, it feels like you might have to overprovision the server running the software, which can become quite expensive.

For example, after installing Veeam, our vulnerability scans flagged the bundled PostgreSQL instance as outdated and identified a critical CVE. Is there a roadmap for keeping bundled components such as PostgreSQL updated automatically, or ensuring that the latest supported version is always included during installation?

It would also be helpful to have a clear dependency matrix that outlines which components, plugins, or services are required for specific Veeam features. Something along the lines of:

If you use Feature A, keep Component X installed.
If you use Feature B, keep Component Y installed.

At the moment, I'd like to remove several plugins and components that are not being used, but I'm hesitant because it's not clear which ones are required to keep the Veeam functionality I depend on running properly.

I spent some time breaking down the contents of the VBR 13.1.0.411 ISO to see where the space is actually going. There appears to be a significant opportunity here to address both the component-selection request and the increasingly large installer.

At a high level, I found approximately:

• Backup: 2.24 GB
• Catalog: 181 MB
• EnterpriseManager: 545 MB
• Explorers: 265 MB
• Packages: 4.39 GB
• Plugins: 6.27 GB
• Redistr: 1.19 GB
• Setup: 829 MB
• Tools: 2.24 GB

[MPECSInc]

It is very disconcerting for folks to get the Configuration Backup report with a [WARNING] because we've disabled _all_ of those excess, and to some superfluous, services!

OPT-IN not OPT-OUT please!

P.

I spent some time breaking down the contents of the VBR 13.1.0.411 ISO to see where the space is actually going. There appears to be a significant opportunity here to address both the component-selection request and the increasingly large installer.

At a high level, I found approximately:

• Backup: 2.24 GB
• Catalog: 181 MB
• EnterpriseManager: 545 MB
• Explorers: 265 MB
• Packages: 4.39 GB
• Plugins: 6.27 GB
• Redistr: 1.19 GB
• Setup: 829 MB
• Tools: 2.24 GB

I came up with a few potential ideas while going through the ISO:

Component selection
I think administrators should be able to choose which optional components are installed, including:

• AWS
• Azure
• Entra ID
• KVM
• AHV
• PVE
• Xen
• Kubernetes
• Cloud Director
• SAP
• Oracle
• IBM DB2
• etc.

The same should apply to the various Explorers. If I'm not using Oracle, Exchange, SharePoint, MongoDB, SAP HANA, etc., I shouldn't need to install those components.

Most importantly, the component selection should be persistent across upgrades. If I intentionally remove a component because I don't use it, the next upgrade shouldn't silently reinstall it.

Enterprise Manager
Enterprise Manager seems like an especially good candidate for being completely independent of the VBR installation.

At minimum, it should be optional during VBR installation. Even better would be having a separate Enterprise Manager installer/ISO so environments that use EM can deploy it independently without carrying the entire VBR installation in the ISO with it.

Packages / redistributables
There also seem to be some opportunities to clean up the contents of Packages.

For example, .NET Hosting and EdgeWebView installers appear to be present in both Packages and Redistr. Is there a reason they are included in both locations?

I also noticed installers for both .NET Framework 4.8 and 4.7.2. Are both actually required by VBR? If 4.7.2 is only there for a legacy dependency, can that dependency be identified and potentially eliminated so the older installer doesn't need to be shipped?

IRIS and MongoDB also caught my attention.[/b] They appear to be under Packages. I think they would fit better in Plugins.

Online vs. offline installer
I'd like to see two deployment models:

• Offline installer: contains everything required for an isolated environment.
• Online installer: contains the core installer and downloads only the components selected by the administrator.

Another option would be a repository/custom ISO mechanism where I select the components I need and Veeam generates/downloads an installer containing only those components.

The online installer could also potentially retrieve the latest supported versions of prerequisites such as .NET, PostgreSQL, and other dependencies rather than embedding potentially outdated copies in every installer. That would make addressing CVEs in those dependencies much easier.

Longer term
There are also some interesting opportunities around further modularization. VBR already has UHAPI, so I'd be interested in seeing whether vSphere/Hyper-V functionality could eventually be treated more like plugins rather than being tightly coupled to the core installation.