Feature Request: Select Components to Install/Upgrade

[JPMS]

I got a scale of the corner that Veeam have backed themselves into tonight.

Moved Veeam to a new server at the weekend and just disabled all the services we don't use (without actually removing any of the tons of unneeded software).

Tonight I got this warning for our configuration backup:
24/02/2026 00:40:58 Warning Failed to connect to AWS plug-in: Failed to login to platform service (ID: [9a8806c7-85c8-4ecd-8eea-f6fde055e802]):
24/02/2026 00:41:02 Warning Failed to connect to Microsoft Azure plug-in: Failed to login to platform service (ID: [89622f35-9e48-424b-9d52-a74dc03b65c2]):
24/02/2026 00:41:06 Warning Failed to connect to Google Cloud plug-in: Failed to login to platform service (ID: [30d473aa-1164-4842-959a-c80a776f8cb6]):

What?! We don't use any cloud services. Everything we utilise with Veeam is local except the backup tapes we store off site.

How much of the Veeam code relies on everything just being there and running even when it is completely unneeded? Someone needs to get your development team by the scruff of the neck and explain "THIS...IS...NOT...HOW...TO...DEVELOP...SOFTWARE"

[HannesK]

Hello,
as mentioned before that we discuss this topic again, I can give the following update:

1. we plan a "feature selection" for the Veeam Software Appliance (no changes for Windows planned in that area).
2. For Windows, we plan to also manage Postgres updates as it is an integral part of the software stack

Best regards
Hannes

[arngrimurm]

I'm going to go on a limb here and blame sales and marketing. Dev's have nothing to do with this decision.

[ksimon]

Sorry for the silence from R&D side on this topic. We discussed this topic internally some time ago as it came up also in other Forum threads and it was internally rejected back then. Having that said, we will discuss again and see whether we could do such things after there were some architecture changes in V13.

I would be very interested in the reasoning behind the hard reject previously.
This seems like something where YOUR clients are using a security product that appears to becoming less secure as time goes on

[ITinSpace]

Hello,
as mentioned before that we discuss this topic again, I can give the following update:

1. we plan a "feature selection" for the Veeam Software Appliance (no changes for Windows planned in that area).
2. For Windows, we plan to also manage Postgres updates as it is an integral part of the software stack

Best regards
Hannes

Hannes,

Thanks for the update. Unfortunately, that doesn't help the vast majority of us that run Veeam from Windows, and have for years, and who also are faced with meeting security requirements set forth by public law, executive orders, agency/organizational security policies, etc. We need a solution to this issue and we needed a solution before this post was even started well over a year ago. This is a horrible way to develop software as it's not best practice and it's also not helping your customers maintain a secure computing environment. We don't have a choice but to comply with the laws and policies that are in place for our environments and Veeam is just making that difficult, if not impossible to comply, and has thus far given us absolutely no reassurance that a solution is forthcoming. What that tells me is that we need to be looking at alternative backup software solutions for our environments. If you can't listen to your customers, you will soon find that you have none.

[JPMS]

1. we plan a "feature selection" for the Veeam Software Appliance (no changes for Windows planned in that area).

Why the disparity?

I suspect this is the start of running down the Windows version of the software in favour of the Software Appliance. I can think of no other reason to not deliver the same installation improvements to the Windows version.

[HannesK]

Hello,
the reason to reject / postpone features is the same "as always": priorities and resource allocation.

The priority for now is to improve the Veeam Software Appliance so that there is (almost) no reason for customers to stay on Windows. We won't be able to secure Windows that is managed by a customer. When it comes to security concerns, then I can only engage everyone looking at the Veeam Software Appliance that was built with security in mind. We might have been a bit too strict on security and will allow less secure options here and there in future.

I agree that the number of services looks bad from a security perspective. "less is better". All agree, as it is what probably everyone learned somewhen in their career. On the other hand: how much would one big backup service instead smaller ones make it better? Yes, it looks better. But if we look at modern architectures (not what Veeam Backup & Replication on Windows is, which was designed almost 20 years ago), then there are more (micro) services than ever.

There are no short-term plans to stop Windows development. As I wrote above, also Veeam Backup & Replication on Windows will get some improvements. But for sure, the focus in on improving the Veeam Software Appliance.

Best regards
Hannes

[RubinCompServ]

"I agree that the number of services looks bad from a security perspective."

The problem isn't (entirely) the number of services, it's the number of UNNEEDED services. If breaking out the application into 20 services made it easier and quicker to patch (because not every service would be subject to a vulnerability so they wouldn't all have to be patched) instead of having to patch the entire bloated application, I'd be all for it. But don't force me to install a bunch of unneeded bloat that just sits there consuming resources and introducing unnecessary vulnerabilities.

[HannesK]

agree yes, and that is something we plan to improve for the Veeam Software Appliance.

[chris.childerhose]

Hello,
as mentioned before that we discuss this topic again, I can give the following update:

2. For Windows, we plan to also manage Postgres updates as it is an integral part of the software stack

Best regards
Hannes

Hannes - does this statement mean that the Postgres "must" live on the Windows server, or will you be able to do this with an external PG server that is connected to VBR? We are going to transition to PG external servers for VCC, and our vCloud VBR servers will migrate to VSA when ready.

[RubinCompServ]

@Chris,

My understanding is that PG is officially not supported on a separate machine. I think the PG component is expected to be local for the EntraID backups. As we don't need EntraID backups, I've been running my PG database on a different machine with no issues.

[chris.childerhose]

@RubinCompServ

I don't recall them saying that for the Windows installation - VSA I can see, since it is built-in. We also have an external PG server and EntraID backups going to it without issues. So that is why I asked as it should be "supported" and fall in to the new management part. Also based on the system requirements page from the help external is supported - https://helpcenter.veeam.com/docs/vbr/u ... tml?ver=13

[RubinCompServ]

@Chris,

That's news to me, and thank you. I had asked about it in the context of v12, and Gostev was very clear (at the time) that PG was only supported locally, and not remote. It was a few years ago (not too long after 12.0) so I can't find the original post, but the documentation seems clear, so I withdraw my previous comment.

[chris.childerhose]

@RubinCompServ

Not to worry as I tend to check the documentation frequently LOL

Hopefully, the external one will be managed for updates. Fingers crossed.

[HannesK]

Hello,
the goal is to have the configuration database always local because that removes latency and simplifies troubleshooting.

Yes, there were times in the past where we had other recommendations or even requirements at a certain size or said to not use Postgres if you are larger than [value] and using Veeam Cloud Connect. Again, the goal is to eliminate all of these limitations (and I cannot remember any current one) and have a local Postgres instance.

While it's technically possible to have remote databases today on Windows (and even on Linux for EntraID backup, but it's ugly), we work on getting these use cases eliminated. The goal is that customers should not worry about the database same as they don't need to worry about "3rd party library XYZ" that we ship with the product.

Best regards
Hannes

[chris.childerhose]

Thanks, Hannes, for the clarity. I will work on my new plans to migrate to PG from SQL but using locally installed PG on the same server (Windows) for VCC. The migration to VSA from my other servers will take care of that regardless.

[josch]

JPMS (look above) mentioned about a year ago a list of unused Veeam tools and addons.
We are running a simple Windows environment too. Looking at installed programs there
are more than a dozen. It's safe to uninstall all of this?

Possibly anyone may show a list of (only) windows environment necessary parts.
There are some, I can't decide to check, if necessary or not. TY!

[RubinCompServ]

While it's technically possible to have remote databases today on Windows (and even on Linux for EntraID backup, but it's ugly), we work on getting these use cases eliminated. The goal is that customers should not worry about the database same as they don't need to worry about "3rd party library XYZ" that we ship with the product.

So will the documentation be updated to exclude remote PG instances?

[chris.childerhose]

I hope this is part of the management solution updating the documentation.

[HannesK]

Hello,
Josh: welcome to the forums. We only test "full installations". While removal might work, we cannot guarantee that everything works.

RubinCompServ: as long as it's supported, it will stay in the documentation.

Best regards
Hannes

[RubinCompServ]

@HannesK,

Then can a note be added that remote databases are supported, but will not be maintained/updated by Veeam?

[chris.childerhose]

That is what I was hoping they would add too. Good call with that @RubinCompServ.

[josch]

Hello,
Josh: welcome to the forums. We only test "full installations". While removal might work, we cannot guarantee that everything works.

RubinCompServ: as long as it's supported, it will stay in the documentation.

Best regards
Hannes

Hannes,

thank you for welcome and for your answer.
I was figuring out with the FAQs how to 'like' a person, but didn't find out, or I'm simply not able to do it yet as a lurker?

Regards
josch

[HannesK]

one can only like "posts" not "people"

for future writers: please stay "on-topic" to make it easier to read. thank you!

[josch]

OFF TOPIC- If you are not logged in, you will miss the LIKE button!

[JPMS]

The priority for now is to improve the Veeam Software Appliance so that there is (almost) no reason for customers to stay on Windows.

...unless you have a sockets license.

Despite Veeam's promise of continuing to support socket licences, the reality is they continue to slowly strangle them (whilst still significantly increasing the renewal cost). Not allowing them on the VSA, which is clearly the future of the product, seems to be forcing the end of socket licences.

[vmikhelson]

+1 to Select Components to Install/Upgrade.

[DE&C]

+1 – mainly for fewer resources and improved security.

I fully understand Hannes’ point. If security is a priority, Windows should not be the long-term option in this context.

for future writers: please stay "on-topic" to make it easier to read. thank you!

This may be slightly off topic, but still related to this discussion:
Frankly, it would not surprise me if Veeam followed VMware’s path and supported the Windows installation for only one or two more major versions before focusing entirely on the appliance, once everything is stable and more modular and lightweight (as discussed in the posts here). I would even welcome this, as it would free up development resources, enhance security overall, and further strengthen the appliance platform.

Socket licensing may be a challenge for some customers, but that is a commercial matter.

[kareldebruyne]

+1

It's my first post, never really felt the need to say something but this has been something I never understood. We only use the bare product, yet we're forced to keep all the bloat up-to-date.

[dabrigo]

Guys please remember to like the starting post, it's the way Veeam evaluates which feature request has priority (+1 is not useful)
Beside this, i second this request, also since Veeam is becoming a huge product to install and maintain. What's the reason of calling them "plugins" if they are mandatory and cannot be removed?