VBR v13 GUI Performance

[cgsm]

I will add to this, the GUI in VBR 13 (installed on Windows, using the Windows application, not the web console) is slowwwwww and laggy. V12 was much faster and smoother. Sometimes when I want to edit a job, the GUI takes nearly a minute to open the "Edit job" window; this seems to be more of an occurrence when a number of jobs are running although CPU/RAM/Disk usage isn't maxed out causing resource contention issues.

[pufferdude]

I find so ugly that every new software is slower and slower. Windows Server 2025 GUI is sooooo sluggish. Sometimes I have opportunity to use some very old Windows Server 2003 or Windows Server 2008 R2 GUI inside some old VM and the GUI is so immediate and quick

Just wanted to respond to this, in case you're running Windows Server 2025 VMs in vSphere like I am. What I've found that UPGRADED VMs (from 2019 or 2022) behave horribly... super slugish moving around the UI, etc (though they seem to actually run IIS, SQL Server and such at normal speed... it's just the GUI that's bad for me.)

However, installing a FRESH Win 2025 VM is a completely different story... very snappy, very responsive, very pleasant. Copilot says this is something to do with Windows 2025 not being able to use new/changed/optimized UI code paths when upgrading (because all settings get preserved) vs. a fresh install that takes advantage of everything new about 2025. All I know is that there's a huge different between upgraded vs. new Win2025 VM GUI performance, for me.

[lreed]

Always remember: we use 20% of features 80% of time. Maybe 10 / 90 with all features packed in VBR. I think Product Management should start to give an "Essentials" ISO to install just Backup / Replication and Cloud Export

I have complained about this before too. There needs to be options not to install all the plugins and the update iso needs to be able to work even if you have uninstalled some of the plugins (yah it will fail if you remove plugins manually). I saved almost 3 gigs of ram on some systems because the idling plugins were eating up large amounts of ram.

[gmbdc]

We've also found v13 incredibly slow. Brand new server, specification way above the recommended specification.

Takes ages for the login box to appear, then a minute for the application to open. If you wish to edit a job, again, you need to wait 30 seconds to a minute. I could go on!

Before in v12, things were much much snappier.

We've also logged a ticket.

[eclipse4ever]

I have complained about this before too. There needs to be options not to install all the plugins and the update iso needs to be able to work even if you have uninstalled some of the plugins (yah it will fail if you remove plugins manually). I saved almost 3 gigs of ram on some systems because the idling plugins were eating up large amounts of ram.

We have been told to disable all extra services/plugins we don't use on our VCC (not a real VBR) server to see if it speeds things up.
When doing this, the backup configuration job fails because the stopped plugin service is not responding....

[iDeNt_5]

It fails or "just" reports a warning?

[eclipse4ever]

Ok, I stand corrected.
It doesn't fail but gives a warning, which would be great to avoid as warnings on a daily basis are a pain and you tend not to spot the real warnings
We just updated to the latest version today, and I feel a little speed improvement

[nd39475]

i feel like the issue is not Veeam subsystems, but rather the design choices around the GUI. Since days of XP there was "standard" Windowing/menu/etc, but for some reason Veeam designed it's on windowing platform or at least so it "seems". In v12, dialog boxes get hidden/stuck behind the UI often for me, and i have no choice but to kill or logout. please implement a "Standard" windowing for the Application.

[scott.anderson]

v13 is not the best release we have seen from Veeam. It's getting the mature software bloat which seems to happen so often in the IT industry unfortunately.

VBR was slim, efficient and just worked. v13 is not.

A good example of that is the good old stop a job option. Do you use Graceful or Immediate. Well, there isn't much point in using Immediate anymore. It's not.

I did an Immediate stop on a HyperV job this morning. 90min later and its still Stopping!

HyperV processing in v13 seems to be very broken. Jobs are taking anything up to 4 times the amount of time they took with v12.3. Same VM's, Same HyperV hosts, just the new and "improved" VBR v13.

Sorry Veeam, but as someone that has been using Veeam VBR for over 15 years this has been a most disappointing release.

[HannesK]

Hello,
as topics are mixed a bit, I try to focus on the title of the topic "VBR v13 GUI Performance".

As always: security software is the most common reason that I personally see when getting escalations. Especially after upgrades, because new exclusions might be needed. If you run security software on the console / backup server, then I can recommend to testing with temporary disabled security software. On the longer run, the web UI will solve that, but as long as the Windows console is needed, security software will probably stay a source of performance issues.

With V13, we rewrote major parts of the Windows Console to become compliant with accessibility standards upgrade older UI frameworks to more modern ones. Besides that, there were also changes in the backend around authentication which can also have side effects. As I run several labs on my own, I can confirm that unpatched V13 had some issues that the latest V12 versions did not have. After the upgrade last week, it feels better, but my labs are obviously not representative for all customer environments.

Question: the ones who have UI performance issues, do they still exist in 13.0.1.2067? If yes, do you maybe have a chance to open a support case and post the case number here?

@kevin.boddy : are you on 13.0.1.2067 already? The case details I see "no", but they are not 100% reliable. I also read in the case that you have multiple cases open. I did not go through all of them. I will also discuss internally the current suggestions support made. Some of them sound strange to me.

@FrancWest : I checked your case and did not find the information that it's a "low priority fix". I only found the information that support does not have details when it will be fixed. I asked for the bug numbers and will check the status.

@StephanHeier : which ticket are you referring to that should be prioritized? This is R&D forum, not support forum. The regular way to prioritize cases is via "my.veeam.com" and "talk to manager". If you post the case number, then I will look into it. Same question to you: are you on 13.0.1.2067 already?

@eclipse4ever: as far as I understood the case, your are running security software that you cannot disable. And you ran https://github.com/lukas-kl/veeam-win-av-script/ which is for Windows Defender and not for your security software. That script might even make it worse if it enabled Windows Defender additionally to your software. The error you see is typical for your security software scenario, but it can also have other root causes. The only way I see is to disable the security software and then see how it goes. Same as before: upgrade to 13.0.1.2067 may also solve it because I remember that issue from my lab and it did not come back after upgrade.

I hope I did not miss anyone with UI issues.

Best regards
Hannes

[kevin.boddy]

Hi,

We updated to 13.0.1.2067 this past weekend. It doesn't make any difference to the GUI performance. It's still slow.

Thanks
Kevin

[FrancWest]

Hi Hannes,

Support wrote me this:

Sorry for the delay, yes I have just confirmed that both issues have been reported to our R&D and they should be handled in future patches, regrettably since they are not critical I don't have an ETA on this.

I read this as ‘low priority’.

[eclipse4ever]

@eclipse4ever: as far as I understood the case, your are running security software that you cannot disable. And you ran https://github.com/lukas-kl/veeam-win-av-script/ which is for Windows Defender and not for your security software. That script might even make it worse if it enabled Windows Defender additionally to your software. The error you see is typical for your security software scenario, but it can also have other root causes. The only way I see is to disable the security software and then see how it goes. Same as before: upgrade to 13.0.1.2067 may also solve it because I remember that issue from my lab and it did not come back after upgrade.

We didn't have any issues running v12.x, so there are performance issues with the new build.
We ran Defender and Arctic Wolf before the upgrade.

We did see a small performance increase after installing the latest build.

[chris.childerhose]

Seeing similar issues and also weird behaviour when you select a job, sometimes the toolbar does not show the edit/etc. functions it is the "Home" layout. You need to switch focus or something to get it working. Latest patch seems to be better, but still happens sporadically.

[jasonede]

Another voice for the option to select which plugins you install. My thoughts are that if you're upgrading it should just show the existing plugins selected. If want to they any new plugins could be highlighted as new, but shouldn't be pre-selected. In a new scenario then should ask you and if none selected just install the base package.

I've upgraded to the latest and it was sluggish. Uninstalling all the plugins didn't need made it quicker, but it's still slower than it was on ver 12.

[HannesK]

Hello,
@kevin.boddy : okay, thanks for confirmation. We are working on it and I see the case is in Tier 2 support now.

@FrancWest: Yes, I saw that statement and support only knows the "planned fix date" of a few critical bugs. With every update, we fix many non-critical bugs.

@eclipse4ever: from my experience (I only see escalations), every update can cause security products to suddenly break our product. It's the majority of escalations on my desk. The only way I see is to temporarily disable all security software and if the problem persists, provide all logs to Veeam support.

@chris.childerhose: please report such bugs to support that we can fix them. As I mentioned, the V13 console had a massive re-write.

Best regards
Hannes
PS: I only answer about GUI performance. For other topics, please use the existing threads / create new threads

[chris.childerhose]

Thanks Hannes. Yeah I am going to do some thorough testing and report it to support. So far with latest patch it seems much better so far. Figures

[FrancWest]

@HannesK: I just upgraded to the latest patch, but now the full view for the statistics pane in the console isn't working anymore. The panel at the bottom of the job list isn't shown anymore. With compact view it does show the panel. Before creating a case, is this a known issue?

[FrancWest]

@HannesK: found it. After the update, the panel divider was completely at the bottom. I had to slide it up to so that the panel became visible again.

[CKNorth]

We're still on Server 2019 and not using Microsoft Defender. Also, the setup is exactly the same than it was on v12. We did an inplace-upgrade from v12 to v13. Right after upgrading, the UI was extremly sluggy. So, I find it smells a bit of distraction strategy to blame other software for v13 being sluggy. Please guys at Veeam, just take this feedback serious: The v13 UI is slow. I assume that it must be a completely different UI-engine now and maybe the choice was not the best decision.
Thank you.

[kevin.boddy]

Hi,

Case #08010936

After a remote session with technical support and feedback from RnD, they acknowledge that the v13 GUI is slower than v12 but they are not going to fix it.
All development is focused on the WebUI, which is missing all the features we actually use, and we must just live with it.

This is very disappointing.

Veeam develops v13, tells us it has less problems than any other release ever and because it's x64 based it will run faster.
The complete opposite is true and they're not prepared to fix the problem.

What I still don't understand is why this wasn't picked up during development?
Why are you using customers to diagnose issues in your software and then aren't even prepared to fix issues when found?

Thanks
Kevin

[m.novelli]

Probably Gostev left Veeam because of the derailed path

Marco

[RubinCompServ]

@m.novelli,

TBH, I think that Gostev was part of the problem. There were plenty of times that issues were reported here and Gostev's response was similar to, "We decided to do it this way so you'll just have to deal with it"

[m.novelli]

Good catch Rubin, you are right also on this

Marco

[eldxmgw]

Hi,

Case #08010936

After a remote session with technical support and feedback from RnD, they acknowledge that the v13 GUI is slower than v12 but they are not going to fix it.
All development is focused on the WebUI, which is missing all the features we actually use, and we must just live with it.

This is very disappointing.

Veeam develops v13, tells us it has less problems than any other release ever and because it's x64 based it will run faster.
The complete opposite is true and they're not prepared to fix the problem.

What I still don't understand is why this wasn't picked up during development?
Why are you using customers to diagnose issues in your software and then aren't even prepared to fix issues when found?

Thanks
Kevin

As already discussed on similar topics for example here:
veeam-backup-replication-f2/veeam-12-st ... 02151.html

or here:
tape-f29/tape-linked-to-hardened-reposi ... 01631.html

... the conclusion is always the same.

Veeam's forums are run by product managers and affiliate marketing pushers disguised as DevOps or technicians, who constantly communicate with the same mantra: "We'll discuss... // ...blah blah..." to keep licensees and the like engaged. This approach rarely yields any results, as evidenced by the countless lines of backlogs. Responses seem inauthentic, like they were churned out in poor management training sessions, lacking conflict resolution skills and adhering strictly to guidelines without clearly addressing the core issue.

Furthermore, forums and problem feedback from unsuspecting customers have been used for years not to refine or further develop the product according to its licensees' needs, but rather to present customers with a half-baked product lacking key features (VSA) or immature, buggy beta bloatware (VBR13). The goal is to then cheaply develop the product into a final version by appealing to customers directly through forums.

The hallmarks of this tactic are clearly recognizable in many backlogs. Whether this is internal policy or calculated is irrelevant. The only thing that should be clear, given the sheer facts, is that people should abandon any preconceived notions that Veeam is customer-centric and authentic.

[HannesK]

Hello,
thanks Kevin for taking the time with support. I have seen the video and agree it's slower. On the other hand, the video is far away from "sluggish", "slowwwwww and laggy" or "extremly sluggy" as others stated above.

The decision was made as you said above: we focus on the Web UI to get it feature complete as soon as possible so that the Windows console is not needed anymore. There are many other complaints about the console about permission requirements, version compatibility, upgrade complexities etc. that the web UI should solve.

Of course, we will continue to listen what our customers say on the forums, which suggestions for improvements they have etc.. And in the end, we will have to make the decisions where to put development resources. As always, whether we like it or not: there is a limited amount of resources.

Best regards
Hannes

[kevin.boddy]

Hi,

My question previously in this thread was "How would I know what is expected or what is not expected from a new software build?"
And the answer was "“Expected” means that our customers are satisfied with the performance."

That is why I am disappointed in the outcome. I am not satisfied with the performance and saying it's not "that" slow or laggy doesn't help when you can directly compare it to a well optimised v12.

Veeam obviously has the engineering team, who worked on v12, that can make a good UI.
If engineering time during the v13 development has been moved to the WebUI then I don't understand why the WebUI is missing some many crucial features still at this stage.

There's obviously nothing anyone outside of Veeam can do about the direction the product is taking but I just hope the product managers are taking note of the issues raise and are not just brushing them aside but working to make the product better.

Thanks
Kevin

[HannesK]

Hello,
the web UI is currently "in preview" (there is a popup at first login). That is where we focus on to get all functionality in there.

The V12 console was unable to pass accessibility standards and had to be ported to a new UI framework. That rewrite is probably one of the reasons the V13 console is slower than the V12 console. If something really breaks / makes the V13 console unusable, then we will work on that. For example the V12 console cannot deal with 40,000 tapes and that had to be fixed. The thing is, that some of these optimizations are only visible if one had that problem in V12.

To summarize: if someone sees long freezes that make the UI unusable, then please let support investigate it. As I mentioned before, most performance issues I get on my desk are related to security software, but there can also be other reasons of course

Best regards
Hannes

[CKNorth]

IMHO it's a shame for such a recognized company as Veeam to constantly trying to deny the facts.
The V13 UI *is* way slower that V12 and it is not related to weak systems or security software.
Please don't take a tech guys for a fool. Thank you.

[crowsprofiles]

Not to defend the product or choices made to create the V13 GUI, but @HannesK has repeatedly stated that they ported it to a new framework and that's "probably one of the reasons the V13 console is slower than the V12 console". Since it seems they're not going to invest meaningful engineering resources in optimizing the GUI, because the goal is a functioning Web UI, security software is probably the only remaining thing to do anything with that can potentially help, and that's why those cases are escalated.

But if the GUI is essentially a dead product, when can we expect a Web UI with feature parity?