Veeam 13 issues after upgrade

[0000Backup0000]

Same issue since 14/03/2026 auto update from 13.0.1.180 → 13.0.1.2067.

Veeam Support - Case # 08023178, opened on the 14.03.2026 and on going.

[GreenEnvy]

Support ticket: 08030155
Also not sure if it is related, but I was unable to generate logs. When I go to 'export logs for this job', the select box that appears is empty, no jobs visible.

[renatorichina]

Just as an information. While our own VBR still have the issue (we have a Nutanix Enviroment), I noticed that maybee it's less common on Hyper-V enviroments: I have upgraded around a dozen of customer installations the past 3 days (all have Hyper-V) from 12.x or 13.0.180 to 13.0.1.2067 and I discovered the guest processing issue only at one single of those customers, while all have at least a job with activated guest processing.

Another thing discovered, which I also find a little strange: I have left for all of the customers Hyper-V backupjobs the default setting for the Backup Proxy, meaning (Off-host backup) with the as well default setting for "failover to on-host backup mode if no suitable off-host proxies available"

However, I've discovered then, that the "Guest Interaction Proxy" was NOT installed on any of the hyper-v hosts after the installation/update to 13.0.1.2067. When I gone through the Properties wizard under "Backup Infrastructre" - "Managed Servers" - "Microsoft Hyper-V", all had the Status "not installed" under the GIP and it has been installed then when I processed the dialog.

Not sure, if this is by design, or this might be a glitch, that the GIP is not installed by default on the host when doing the update/upgrade to 13.0.1.2067.

#08022476 (our own Nutanix GIP issue) now escalated to next tier support and under investigation by RnD team according to the newest status of today

[david.domask]

Hi Renato,

Thank you for sharing the details, but for items not related to the topic, it's best for another topic so we can keep this one on topic; in your case since it's being investigated already, no need for a topic unless you have questions about the results of the case.

[magrichad]

Case: #08026088

I Would also like to provide some extra info on what I noticed on our Nutanix cluster. All our physical servers (agents) are working fine. All our AHV Windows 11's are working fine. All our Linux/etc VM's are working fine.

Almost all our AHV Windows Servers are not working with the exception of one! There is nothing special about the one that is working. It's on the same VLAN and uses the same credentials as the other Windows servers, it's also on the same domain. Very strange behaviour.

I also had to manually update the proxy worker as the patch did not do that, like the others have reported.

[TAnderson]

Adding my case if it will help Case # 08024663

Similar issues that sound identical
Nutanix backups worked fine until I applied the critical patch last Friday (3/13) then any Nutanix App Aware job started failing
Tech assigned is not addressing the elephant in the room that this patch is what triggered the issue. I have reverted my Veeam server to a backup from Thursday night and run the jobs, they work fine. I snapshot the Veeam Windows server then apply the patch. App Aware backups fail. Revert the snapshot, backups work.

Based on the comments here I manually copied over the deployment kit, no change in behavior. Getting errors like
Failed to prepare guest for hot backup. Error: Failed to connect to the guest OS.
Failed to install guest processing components for <COMPUTER> Error: Failed to connect to the guest OS.

Failed to prepare guest for hot backup. Error: Cannot start service. Machine: [<COMPUTER>]. Service: [VeeamGuestHelper]. Cannot start service. Win32 error:The service did not respond to the start or control request in a timely fashion. Code: 1053
Failed to install guest processing components for <COMPUTER> Error: Cannot start service. Machine: [<COMPUTER>]. Service: [VeeamGuestHelper]. Cannot start service. Win32 error:The service did not respond to the start or control request in a timely fashion. Code: 1053

Failed to prepare guest for hot backup. Error: Cannot start service. Machine: [<COMPUTER>]. Service: [VeeamGuestHelper]. Cannot start service. Win32 error:The service did not respond to the start or control request in a timely fashion. Code: 1053
Failed to install guest processing components for <COMPUTER> Error: Cannot start service. Machine: [<COMPUTER>]. Service: [VeeamGuestHelper]. Cannot start service. Win32 error:The service did not respond to the start or control request in a timely fashion. Code: 1053

Technician assigned suggested I change app aware to Ignore Failures so I would get crash consistent backups and now we get

Warning : Failed to prepare guest for hot backup. Details: Failed to connect to the guest OS.
3/20/2026 12:10:34 PM Warning : Skipping guest VM freeze...
3/20/2026 12:10:40 PM Warning : Skipping guest VM unfreeze...
But we are getting some sort of backup, doesn't help with my recovery of SQL and confidence with recovering AD but it is what it is.

Unfortunately I cannot tell if it's limited to Nutanix backups because coincident with upgrading to Veeam 13 my Hyper-V repository decided to go on a bender and not backup because it is out of sync. This is a separate issue in my opinion.

Veeam server non-domain joined Windows 2016 fully patched
16GB RAM
8 vCPU's
Not migrating to appliance until all these issues are addressed

[homerjs]

any news?
i have the same problem

[homerjs]

Case #08023462

Application-aware processing fails for all backup jobs on Windows Server 2025.
March 15, 2026 8:43:12 PM Failed: Failed to prepare guest for hot backup. Error: Cannot start service. Machine: [xxxx]. Service: [VeeamGuestHelper]. Cannot start service. Win32 error: The service did not respond in time to the start or control request. Code: 1053
Everything was still working in version 13.0.1.1071

[Henrik.Grevelund]

Hi There,

Same issue. Case # 08022140

Really hope this gets fixed soon.

[cdlansys]

Hello,

add also my case to this: Case #03716419

[david.domask]

A small update, we're still actively reviewing the behavior with Veeam RND and working on a resolution for this -- please continue to open Support Cases to track the issue, Veeam Support has guidance on identifying the issue and will inform of the current status. Regrettably no workarounds have been identified, but no further isolation testing should be required at this point, we are awaiting further results on the research.