Win32 error: The network path was not found. Code 53

A server processed by a job fails with the following error:
 

Error: Failed to connect to guest agent. Errors:
'Cannot connect to the host's administrative share. Host:  [<hostname>]. Account: [...].
Win32 error:The network path was not found.
 Code: 53
Cannot connect to the host's administrative share. Host:  [<ip>]. Account: [...].
Win32 error:The network path was not found.
 Code: 53

 

Note: This applies to both VMware and Hyper-V environments.

This error occurs when Guest Interaction Proxy ( vSphere | Hyper-V ) fails to connect to the Guest OS while attempting to perform Application-Aware Processing ( vSphere | Hyper-V ).

The Guest Interaction Proxy will attempt to connect via the hostname first and may fail if it cannot resolve the IP address.
If the Guest Interaction Proxy Fails to connect to the guest Admin Share by hostname, it will try to use the IP reported to the Hypervisor.

The Win32 error, "The network path was not found," is received by Guest Interaction Proxy from the OS when it attempts to connect to \\<guest-hostname\ip>\admin$

• Disable the firewall inside the Guest OS temporarily. If the Guest Credentials Test and the Job work with the Firewall disabled, review the User Ports list (vSphere | Hyper-V) and make adjustments.
  
• Make sure the Windows time on the Veeam Backup server and Guest Interaction Proxy is the same as the guest OS.
  
• Make sure File and Printer Sharing is enabled in the guest OS.
  • ​Once File and Printer Sharing is Enabled on the guest OS, ensure the Firewall rules are set to allow traffic for File and Printer Sharing.
• If the guest OS is Vista/2008 or later:
  • In the Network and Sharing Center, if the network is set to 'Public' the firewall will be locked down and block traffic.
  • Verify that the Remote Registry Service is started.

Note: When working with vSphere environments, it is possible for Veeam Backup & Replication to use a network-less connection method (VIX) if direct communication fails. This method uses VMware tools to push the runtime components into the machine and manage them. If the VM being protected is in a DMZ or other network isolated configuration, it may not be possible to get RPC working and require that connectivity via VIX be investigated. Reference: https://www.veeam.com/kb1788.

Forcing VIX in Isolated Environments

If Veeam Backup & Replication will be operating in a vSphere environment where the Veeam server and its components will never have direct network connectivity to the Guest OS of the Virtual Machines, it is possible to force VIX to be attempted first.

Create the following registry value on the Veeam Backup & Replication server:

Key Location: HKLM\SOFTWARE\Veeam\Veeam Backup and Replication\
Value Name: InverseVssProtocolOrder
Value Type: DWORD (32-Bit) Value
Value Data: 1

To disable (default behavior), set the value to 0 (false)

 

For Veeam Backup & Replication 9.x and later, you should also create the value on the Guest Interaction Proxy
(note that the path is different)

Key Location: HKLM\SOFTWARE\Wow6432Node\Veeam\Veeam Backup and Replication\
Value Name: InverseVssProtocolOrder
Value Type: DWORD (32-Bit) Value
Value Data: 1

To disable (default behavior), set the value to 0 (false)

Veeam Service restart is not required.