Failed to create persistent connection to ADMIN$

[sunnyIT20]

solution is to set password to local "Administrator" account via elevated cmd line, then enable it:
net user Administrator "newpassword"
net user administrator /active:yes

Silly veeam doesnt handle this or offer a prompt and or instruction.
Cheers

[davidkillingsworth]

solution is to set password to local "Administrator" account via elevated cmd line, then enable it:
net user Administrator "newpassword"
net user administrator /active:yes

Where do you issue these commands? On the VM guest themselves, or on the Veeam Backup server?

[Regnor]

You do this on the guest VM. What it basically does is enabling the local Administrator so that you can use this account for backup.
An alternative would be to set the LocalAccountTokenFilterPolicy registry key, which enables every local axcount to connect.

[davidkillingsworth]

Ok, noted. We had already enabled the LocalAccountTokenFilterPolicy registry months ago to get this working.

[kierank]

None of the solutions above worked for me. I got the error 'Failed to create a persistent connect to ADMIN$' with error code 0x00000035.

Mine was a particularly complicated setup across several data centres, but long story short, I'd suggest double-checking outbound firewall rules for TCP 6160-6163. It was difficult to test these ports beforehand because initially there was nothing listening on those ports. All other port tests succeeded and I could browse to the ADMIN$ share in windows explorer without issue, even using the same credentials defined in VBR. So in effect, the error suggesting otherwise is just plain misleading. It's a real pity the Veeam error / logs don't suggest that a specific port(s) could be the issue.

Feature request - build a quick and basic port test into the 'New Server' wizard.

[AlexHeylin]

@kieranuk - having also had port problems, I agree that a quick port test option in VBR could save a lot of time in firewalled / segmented deployments. I've run into these problems myself, and discovered that the documentation didn't clearly list EVERY port required (now fixed). I suggest you open a new thread with [Feature Request]..... as the title though so it's clear and invites feedback - rather than tacking it onto an existing old thread.

[PetrM]

Hello,

I really doubt that we'll implement a port tester in any of our wizards, but you should refer to this page for the required ports. If something is missing, please let us know and we'll update our documentation.

Thanks!

[colohost]

Just a +1 to this silly problem. I have a current v12.1.0.2131 VB&R enterprise install with a win 2016 master, win 2012 proxy, ubuntu proxy. I'm adding a Windows 11 proxy to gain access to BBR TCP congestion control as I need to start replicating over WAN and that improves performance dramatically. So what do I do, I install Windows 11 Pro from scratch, do nothing more than add a local admin account for Veeam to use, RDP into it to make sure it's happy, and then tell Veeam to use the same account and I get the error about ADMIN$.

The registry hack allowed the install of the proxy agents to continue.

So, what am I supposed to do to undo the registry change and have things working properly?

[PetrM]

Hello,

I suggest using the persistent agent components for guest processing, admin$ is required only for the first job run which will install the persistent components in the guest OS.

UPD 01/03/2024: admin$ is not required, persistent agent components are installed via Veeam Installer Service.

Thanks!

[AlexHeylin]

@PetrM - from when I ran into this, unfortunately this still requires getting a connection to ADMIN$ to install the persistent agent. In most cases if that worked, then there'd be no problem running the non-persistent agent. Manually installing the persistent agent to the VM doesn't work due to the logic used in the job. IIRC if the job detects the agent but not the installer service (which it would have used to remotely install the agent) then it will hard fail that VM backup. I queried this logic and was told the logic was right, but I was trying to do something unsupported by manually installing the agent directly in the VM (which IMO is the best use case for the persistent agent).

[Regnor]

Hey Alex! If I remember it correctly I deployed the installer service manually before connecting/deploying the persistent guest agent. Have you tried this so far?
This is also described in the helpcenter: https://helpcenter.veeam.com/docs/backu ... ml?ver=120

[PetrM]

Hello,

Regnor is right, you must ensure that the Veeam Installer Service is installed on the guest VM to use persistent agent components (I updated my post above as I provided an incorrect statement about first job run). Also, please have a look at the diagram on this page, it explains the workflow.

Thanks!

[AlexHeylin]

Hey Regnor, It was some time ago, but I think we gave up and took another route to get it working (I can't remember what). I don't think I was aware that manually installing the installer service was supported. Thanks.