Win32 error: The network path was not found. Code 53
Challenge
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.
Cause
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$
Solution
The key to troubleshooting this issue is identifying the environmental problem preventing the Guest Interaction Proxy from connecting to the $admin share of the server being processed.
Tip: To test connectivity to the $admin share rapidly without running the job, use the "Test Now" button on the Guest Processing tab of the job to launch the Guest Credentials Test.
Troubleshooting:
- 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 a connectivity issue specific to one of the Guest Interaction Proxies
- Make sure the Guest Interaction Proxy can access the VM
- ping the hostname and IP
- Test connectivity to port 445
Test-NetConnection -computername <hostname\ip> -port 445- 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.
- Ensure 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.
More Information
Networkless Guest Processing in vSphere Environments
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 VIX/vSphere Web Services 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 VMware 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 network-less guest processing connection (VIX) to be attempted first.
Note: Veeam Services do not need to be restarted. The registry setting will go into effect on the next job run.
For all Veeam Backup & Replication Versions:
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
0 = Try RPC (admin$ share) first, then failover to VIX. (Default behavior)
1 = Try VIX first, then failover to RPC (admin$ share)
For Veeam Backup & Replication versions 9.x through 10a:
For older versions, the registry value must also be created on each Guest Interaction Proxy that the Backup Job will use.
>>>note that the key is different<<<
Key Location: HKLM\SOFTWARE\Wow6432Node\Veeam\Veeam Backup and Replication\
Value Name: InverseVssProtocolOrder
Value Type: DWORD (32-Bit) Value
Value Data: 1
0 = Try RPC (admin$ share) first, then failover to VIX. (Default behavior)
1 = Try VIX first, then failover to RPC (admin$ share)
Networkless Guest Processing in Hyper-V Environments
When working with Hyper-V environments, it is possible for Veeam Backup & Replication to use a network-less connection method (PS Direct) if direct RPC communication fails. This method uses PowerShell Direct to push the guest processing runtime components into the machine and manage them.
Forcing PowerShell Direct in Isolated Environments
If Veeam Backup & Replication will be operating in a Hyper-V 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 network-less guest processing connection (PS Direct) to be attempted first.
For all Veeam Backup & Replication Versions:
Create the following registry value on the Veeam Backup & Replication server:
Key Location: HKLM\SOFTWARE\Veeam\Veeam Backup and Replication\
Value Name: HvVssPowerShellDirectPriorityOverNetwork
Value Type: DWORD (32-Bit) Value
Value Data: 1
0 = Try RPC (admin$ share) first, then failover to PowerShell Direct. (Default behavior)
1 = Try PowerShell Direct first, then failover to RPC (admin$ share).
Note: Veeam Services do not need to be restarted. The registry setting will go into effect on the next job run.
To report a typo on this page, highlight the typo with your mouse and press CTRL + Enter.