Veeam 11 Remote Console Changes

[aich365]

Support have advised KB4126 but it will be 2 weeks before we can implement this as the Service will need to be taken off-line

[ashleyw]

Hi, we have been running patch release 11.0.0.837 P20210525. since it came out, and the Veeam console is still exceptionally slow (about 2-3 minutes to start up) when connected via a VPN link (using OpenVPN). The VPN itself is not slow but as others have said any VPN is going to add some small latency and jitter to the traffic.
We've seen other apps misbehave like this when they involve a lot of chatty traffic.

We do not see the issue when using VDI on the same LAN as the backup host itself, so the Veeam console traffic is obviously not optimal for WAN/VPN scenarios.
I'm sure Veeam would be able to see this by quickly using a packet sniffing tool like Wireshark.
For now we are going to revert to VDI sessions using either RDGateway/Guacamole to VDI on the same LAN as the backup host.

thanks
Ashley

[Egor Yakovlev]

Hi Ashley,

Please contact Veeam Support. This issue is under thorough investigation with a private fix available (support must check your infrastructure conditions first).
This private fix was not included into the latest cumulative patch.

/Thanks!

[ashleyw]

thanks Egor, I have logged a case; #02218233
Looking forward to the response!
On a related note to this, in the future, I'd much rather see a full functional html5 client to avoid any client installation (like vcentre has been running for a log time) but the client a lot richer than the current Veeam Enterprise Manager.

thanks.

[ashleyw]

hi, Just to save everyone's time, apparently the fix was applied already to 11.0.0.837 P20210525. In our specific case applying the patch on top of P20210525 broke the Veeam console completely, and the root cause was a lock in the database table which Veeam kindly resolved for me by doing a; DELETE FROM [dbo].[Options] WHERE name = 'lock_info' on the Veeam database.

The issue with the slowness of the console over WAN/VPN has now been acknowledged and reproduced within Veeam and a fix being worked on as I understand it.

From my perspective, these types of application level issues are not easily resolvable as it would require a re-architecture of the client to significantly reduce the call backs to the server back end, so in our case we'll revert to using VDI/RDP on the same LAN subnet as the backup host.

There is certainly a use case for a lighter but much richer HTML5 style of client that provides similar functionality to the existing thick client.

thanks.