Fix: Error 53 ERROR_BAD_NETPATH with Veeam Agent for Windows 2.1

Background

I have previously written a blog post about Veeam Agent for Windows management with Veeam Backup and Replication 9.5 U3. In that post, I mentioned the agent upgrade process was not entirely plane sailing. Initial upgrade results in an Error 53 ERROR_BAD_NETPATH error which is a generic Windows error when the source computer cannot contact the destination computer. So what does that look like?

The problem

When trying to upgrade the agent through an agent protection group, I received the following error.

The Fix

Ok, so whats up with that? First thing I checked was, could I browse the machine via UNC path \\win7demo\c$. This did not work. As the test machine was not domain joined, I had to disable User Access Control to allow remote access to default hidden system shares using local credentials on the Win7Demo machine. I am sure there is a better way to achieve this, but this is what I did.

So great, I could now browse to the target machine by UNC path, but the error still persisted in Veeam. A little further digging on the interwebs suggested running the following command from a command prompt to replicate the error.

Sure enough, this generated the same error. To work around this error, I had to enable NetBios on the NIC on the target machine (Win7Demo) to allow name resolution.

Trying the net use command again from the command line worked on the Veeam server, as below. So Net Use and UNC path now work.

Trying to run the discovery job again in Veeam still failed, this time with a new error that the credentials were incorrect.

This one was my fault, the credentials should be specified as computername\username. I specified them as .\username. Surely the job should work after this? Oh hell no.

The final pointer that I found at the bottom of the following Veeam KB for a similar issue is that the remote registry service should be running on the target machine.

Once I had enabled this, the agent upgrade proceeded as expected.

Now had the target computer been domain joined, I don’t know if I would have experienced these issues. If I had just started with a clean machine and deployed the 2.1 agent direct, rather than trying to upgrade an old version, again this may have just worked. For me at least, none of my ducks were in a row at the outset. Changing the settings as above resolved the issue.

 

Ian