#1 Global Leader in Data Protection & Ransomware Recovery

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

KB ID: 1230
Product: Veeam Backup & Replication
Published: 2011-09-28
Last Modified: 2023-08-18
Languages: DE | FR | ES
mailbox
Get weekly article updates
By subscribing, you are agreeing to have your personal information managed in accordance with the terms of Veeam's Privacy Notice.

Cheers for trusting us with the spot in your mailbox!

Now you’re less likely to miss what’s been brewing in our knowledge base with this weekly digest

error icon

Oops! Something went wrong.

Please try again later.

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

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$

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.

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)

Note: Veeam Services do not need to be restarted. The registry setting will go into effect on the next job run.

 

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 Location 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)

Note: Veeam Services do not need to be restarted. The registry setting will go into effect on the next job run.

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 submit feedback regarding this article, please click this link: Send Article Feedback
To report a typo on this page, highlight the typo with your mouse and press CTRL + Enter.

Spelling error in text

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.
Thank you!

Thank you!

Your feedback has been received and will be reviewed.

Oops! Something went wrong.

Please try again later.

You have selected too large block!

Please try select less.

KB Feedback/Suggestion

This form is only for KB Feedback/Suggestions, if you need help with the software open a support case

By submitting, you are agreeing to have your personal information managed in accordance with the terms of Veeam's Privacy Notice.
This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.
Verify your email to continue your product download
We've sent a verification code to:
  • Incorrect verification code. Please try again.
An email with a verification code was just sent to
Didn't receive the code? Click to resend in sec
Didn't receive the code? Click to resend
Thank you!

Thank you!

Your feedback has been received and will be reviewed.

error icon

Oops! Something went wrong.

Please try again later.