Failed to create persistent connection to ADMIN$

[rafael.reimer]

Hello,

We are deploying an environment based on Windows 2012 R2 STD in a workgroup ( not domain ). At the moment in wich i try to add any Managed Server i receive the message: "Failed to create persistent connection to ADMIN$".

Note: I am NOT using the local "Administrator" to do this, i create an account named "adm.veeam" on servers within the "Administrators" group. If i try to "\\server\c$" with my "adm.veeam" i can't login in the server share.

But, if i try to use the "LOCALHOSTSERVER\Administrator" i can connect in the Windows Explorer and install the Veeam agents.

In a search in the forum i see some references to make some registry entries and all are done. So, why i can't use the created account to connect in the servers and install Veeam ?

[nielsengelen]

It basically means that the account (adm.veeam) you are using does not have access to the ADMIN$ share on the machine you are trying to deploy the Proxy services to. As you have tried to connect to it and you get a failure.

Could you check if remote UAC is enabled? If this is you can disable it with the following reg key:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System.

Create a DWORD value called LocalAccountTokenFilterPolicy and assign it a value of 1.

Then all you need is a reboot of the server and it should work fine.

[denit]

Hi Niels,

Is disabling UAC really the only way forward?
Reason i ask this is because i have installed more than one Veeamserver and infrastructure and i never disabled this.

However, today i have installed another veeamserver and i get this error when adding a proxy.
The proxy resolved by DNS perfectly, i have disabled the firewalls on veeamserver and proxy and i have tried several admin accounts.

This must be a simple thing to solve, but i am baffled at the moment.

[denit]

I managed to solve it, it was my own mistake probably.
I checked everything from scratch again, username (and specially how i type it) , servername, firewall.

I noticed the firewall is not the issue.
I think it was the way i typed the username. I was using local useraccounts and i have doubts on how to type that in the credentials screen. Because of this i created a domain\username and added it to the local administrators group on the proxies.

This seemed to do it. I had trouble with the local accounts by adding them like this ".\username".
I should, next time, immediately create domain service accoutns only.

[annhwebster]

Thank you, I had the same issue. ".\username" was the solution

[dirch]

Got the same error.
The solution was a registry fix mentioned in another forum thread from 2011.

My setup was 2 Windows 2012R2 servers in a domain.
If i tried to add the proxy using these accounts it worked:
- domain account, like domain\useraccount
- with the proxy local administrator, like proxyserver\administrator or IP\administrator (10.10.0.44\administrator)

If i tried the exact same thing with a local administrative user from the proxy server it did not work:
- proxyserver\veeamuser or IP\veeamuser or .\veeamuser

Tried creating another local admin account but got the same error.
Tried the veeam checklist: FW, UAC, File and printer sharing, VSS remote registry etc and access to admin$ worked fine.

The only that made it work was a old Veeam-forum write from 2011 which described a registry fix that is describe my MS as "This value enables the remote administration of the print drivers on a server within a workgroup.":
https://forums.veeam.com/veeam-backup-r ... t9612.html
https://support.microsoft.com/en-us/hel ... -on-a-wind
_________________________________________________
Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System]
"LocalAccountTokenFilterPolicy"=dword:00000001
_________________________________________________

Thank you stevenrodenburg1.

BR lars
I

[Helferlein]

Thanks for that Lars
Thougt I'm going crazy....

That registry entry did the trick even without reboot!

[colohost]

Just wanted to add some input to this old thread; doing a fresh install on Windows 2016 servers and receive the same error when trying to connect the master to the first proxy. I didn't have to do any of the registry tricks, etc., but I did have to use the "Server Manager" and enable the file server role, along with using the username format PROXYSERVERNAME\username for the remote connection from the Veeam installer on the master. Even though the appropriate firewall rules were enabled on the proxy manually, I could not get around the ADMIN$ error until doing that role addition in server manager.

[sam.woz]

Adding the LocalAccountTokenFilterPolicy to the registry was the only fix for me as well. Server 2016 using a local non-domain/non-Administrator account. We use non-domain accounts for extra segregation for backup data, so glad to find the solution! Thanks!

[ortoscale]

Reghack did the job. Important, close wizard and start it again. Otherwise you can close yourself into non-working loop forever. Just like I did .

[Harald]

Thanks all, I'm currently setting up Veeam 10 with two physical proxies based on Win 2019 - and guess what, I had to set the RegKey to get it working with an account other than local administrator on the proxies. So, this issue is still present, and maybe it's worth to add it to the installation documents.

[JamesMcG]

Same here for v10 on 2019. Veeam should have the installer add this DWORD during setup.

[Gostev]

Then we will make the news as a trojan horse, because this setting disables UAC which is really bad for security.

[dwageman]

Ok Gostev, but then what is the recommended fix?

[Gostev]

Using local "Administrator" account (this one will work through UAC). See the thread above for details. Thanks!

[wross]

What if the "Administrator" account name is changed? I assume it will continue to work through UAC?

[foggy]

Correct, as it will continue to use the same SID.

[Zew]

A little late to the party, I took the information here and else were and did a "Things to check" guide for each error you might come across in the "add Windows Managed Server Wizard".

If you hit this error then most of the network layers are not the problem and like mentioned it's just the UAC problem.

If you are interested here is the link to my blog and the specific post on this issue.https://zewwy.ca/index.php/2020/09/08/v ... ed-server/ (100% Free, No Ads). Cheers stay safe everyone!

[spencer_rrs]

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System]
"LocalAccountTokenFilterPolicy"=dword:00000001

This fixed my issue on a stand alone Windows Std 2019 Hyper-V host. Username was put in as "SERVER\Username" and no reboot needed. Thanks!

[dlapointe]

It basically means that the account (adm.veeam) you are using does not have access to the ADMIN$ share on the machine you are trying to deploy the Proxy services to. As you have tried to connect to it and you get a failure.

Could you check if remote UAC is enabled? If this is you can disable it with the following reg key:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System.

Create a DWORD value called LocalAccountTokenFilterPolicy and assign it a value of 1.

Then all you need is a reboot of the server and it should work fine.

I had the same issue which this registry key fixed for me in the past. I don't know why today it did not work on a new Workgroup server I wanted to add to Veeam Backup & Replication. But I also needed to change the policy on my workgroup server to make it work (as well as adding the registry key):
Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options\Microsoft network server: Server SPN target name validation level to Off

Note: I am using CIS Hardening GPOs which might be the root cause of my issues thought.

[davidkillingsworth]

I just stumbled onto this problem. We are using Veeam 11 Community Edition.

I have 4 Hypver-VM Windows 2019 VM guests that are all standalone (workgroup). We do not have an active directory domain in our environment.

They were all backing up fine for 3 months and for whatever reason, the VM guest that we installed Firebird 3.0 (https://www.firebirdsql.org) open source database server on started failing that same night. At first it was confusing because we also upgraded from Veeam 10.5 to Veeam 11 on the same day.

I could NOT access HOSTNAME\c$ or HOSTNAME\admin$ from another server, so the problem was at the Windows level. I don't think it was the Veeam upgrade.

The error:

Failed to create VM recovery checkpoint (mode: Veeam application-aware processing) Details: Unable to perform application-aware processing because connection to the guest could not be established
Error: Unable to perform application-aware processing because connection to the guest could not be established

I checked Firewall, VLAN security, Windows Firewall, Windows Defender, File and Print Sharing enabled. Everything was in order, I double and triple checked. All 4 VM guests are installed exactly the same way as fresh Windows 2019 servers as of 3 months ago. We only had problems with this 1 VM guest, and only after it had been working fine for 3 months.

We were also using HOSTNAME\Administrator password in Veeam for the guest process. The password was correct and had not changed.

We were NOT using .\Administrator or just Administrator

I was pulling my hair out until I found this and other blog posts talking about the same.

I created the following registry entry and rebooted, and it is now working without error:

Code: Select all

Key: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System
Value: LocalAccountTokenFilterPolicy
Data: 1 (to disable, 0 enables filtering)
Type: REG_DWORD (32-bit)

[AlexHeylin]

Veeam need to document and fix this. They seem to be intent on ignoring this "known" issue, and certainly not telling customers so they can workaround it.

FWIW - I get this and CAN create a persistent connection to the admin$ share via net use running as the backup service account, so this "it's not us it's MS" excuse seems thin to me.

Veeam Support - Case # 04929878

[Egor Yakovlev]

Please note that "net use" just mounts the share. You don't need elevated local account for it.
However, after connection to admin$, same account is used inside guest to run temporary Veeam helper that we upload using said share. And that's where UAC on Windows kicks in, restricting us to operate.

I do agree that error message text can be more descriptive, and will check if we can determine the "connection to the share is OK, but can't proceed any further" case.

p.s. VBR11 introduced Persistent Guest Agents that use less ports, do not require admin$ at all, are more secure and are not re-deployed between runs. #recommend! Still must take care of UAC though.

/Thanks!

[Zew]

davidkillingsworth - You just implemented the last, and worst solution to the problem (You disabled UAC on your Veeam server). Just an FYI...

[davidkillingsworth]

@Zew, absolutely nothing else would work.

@Egor Yakovlev thanks for the heads up on V11 feature. When this issue comes up again, we'll look to utilize the new V11 method for handling this issue.

[Zew]

@davidkillingsworth - Strange, from my testing and blog post, non domain joined machines should have worked with the "HOSTNAME\Administrator" account. *NOTE* Other accounts with admin rights didn't seem to work, it had to be the builtin Administrator account.

@Egor - "p.s. VBR11 introduced Persistent Guest Agents that use less ports, do not require admin$ at all, are more secure and are not re-deployed between runs. #recommend! Still must take care of UAC though." What do you mean by Still must take care of UAC?

[Egor Yakovlev]

I mean we need to get into machine to install a persistent agent in the first place, unless you want to handle the installation of packages yourself.

[davidkillingsworth]

@davidkillingsworth - Strange, from my testing and blog post, non domain joined machines should have worked with the "HOSTNAME\Administrator" account. *NOTE* Other accounts with admin rights didn't seem to work, it had to be the builtin Administrator account.

@Egor - "p.s. VBR11 introduced Persistent Guest Agents that use less ports, do not require admin$ at all, are more secure and are not re-deployed between runs. #recommend! Still must take care of UAC though." What do you mean by Still must take care of UAC?

As my post states above, we were in fact using the built-in Administrator account. What's more is that the backups had been running fine for 3 months until we installed some software on the VM guest that included Firebird SQL and for whatever reason after that install, the guest processing for the veeam backup would not work.

[Zew]

Weird thanks for the added info, my testing unfortunately didn't include installation of third party software on the end machine. I honestly can't even think of what it could have changed to make that not work.

[Zew]

Not sure if you read this David...vmware-vsphere-f24/v-11-lacks-backwards ... 74994.html it seem there's something that changed, seem to be in V.11 that other are mentioning the same thing as you, HAVE to disable UAC for it to work. Follow along that thread for more details. I personally haven't experienced this, however I'll update my blog post to mention it.