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

This error occurs when Guest Interaction Proxy ( vSphere | Hyper-V ) fails to connect to the Guest OS of a server 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 is unable to 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$

The key to troubleshooting this issue is to identify what environmental issue is preventing the Guest Interaction Proxy from connecting to the $admin share of the server being processed.

To test connectivity to the $admin share rapidly without having to run the job, use the "Test Now" button on the Guest Processing tab of the job to launch the Guest Credentials Test.

The following is a list of common troubleshooting steps.

• Test connectivity to the $admin share (for example, \\<hostname>\admin$) from the Guest Interaction Proxy with the same credentials specified in the Guest Process section of the job.
  Test from multiple machines including the Veeam Backup & Replication server and other Guest Interaction Proxies to isolate if there is connectivity issue specific to one of the Guest Interaction Proxies
   
• Make sure the Guest Interaction Proxy is able access the VM
  • ping the hostname and IP
  • Test connectivity to ports 139 and 445 (test-netconnection --computername <hostname\ip> -port <port>)
     
• 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 in 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, make sure 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 it's 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:

• HKLM\SOFTWARE\Veeam\Veeam Backup and Replication\
• DWORD: InverseVssProtocolOrder
• Value = 1
• To disable (default behavior), set the value to 0 (false)

For Veeam 9.x and later the value should also be created on the Guest Interaction Proxy
(note that the path is different)

• HKLM\SOFTWARE\Wow6432Node\Veeam\Veeam Backup and Replication\
• DWORD: InverseVssProtocolOrder
• Value = 1
• To disable (default behavior), set the value to 0 (false)

Restarting of services in not required.

For more information on VIX permissions, see http://www.veeam.com/kb1788