I have also tried supplying credentials for HOST\Administrator on the hypervisor, which gave the same results as the other local admin account I have been trying. Event log entries on the hypervisor show these attempts, so they are being received, processed, and rejected. I don’t know why.
The issue is caused by the UAC on the Hyper-V host itself. This is a common problem when working with local users.
Can you maybe use the builtin ‘Administrator’? This account is excluded from the remote UAC.
As an alternative you would either have to set the LocalAccountTokenFilterPolicy in the registry or disable UAC, but both need a reboot afterwards.
https://www.veeam.com/kb4185
csmithconvergence,
I may be able to help you with this.
This will require a restart of the Hyper-V host.
On the Hyper-V server, open Regedit as an Administrator.
Go to:
\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System
Open EnableLUA and set the Value to 0. It will probably tell you a reboot is required.
If you haven’t done so, disable the Windows Firewall on Domain, Private and Public. Once the Veeam components are installed, you should turn the Firewall back on.
Assuming your network is allowing the needed ports between the VBR sever and Hyper-V server, these changes should allow the installation of the Hyper-V stuff.
I tried the Administrator account as well and it yielded the same result. However, that administrator account DID allow me to browse to the hypervisor C$ share in file explorer.
I also tried disabling both firewalls entirely (Veeam server and hypervisor), and that didn’t have any effect on the issue either.
Thanks for the suggestions so far - the only thing I haven’t tried is fully disabling UAC on the hypervisor, but I can try to get a maintenance window to do that. That said, the Administrator account should be exempt from UAC, and it failed too. Thoughts?
I have also verified that the admin approval mode policy is still disabled, as per the KB article linked above.
My company policy is to never use the Administrator account for anything. As such, I create an account which is a member of local administrators and use that. Perhaps that is why I must desable UAC.
Sorry I have no other suggestions as the steps I outlined have always solved the problem you posted for me.
The builtin administrator account should work out of the box. That's also the reason why you can access the admin shares with it. So maybe you're now running into another issue. Did the error message from Veeam change with the administrator? And in what syntax did you add the account in Veeam?
The builtin administrator account should work out of the box. That's also the reason why you can access the admin shares with it. So maybe you're now running into another issue. Did the error message from Veeam change with the administrator? And in what syntax did you add the account in Veeam?
I thought it was telling that I could access the admin shares as well. I used the syntax of HOST\Administrator as it is not domain-joined, and I quadruple-checked the password. The error message is the same with the administrator account, though.
Maybe check the permissions guide to see if you are missing anything but the suggestions above should work - https://helpcenter.veeam.com/docs/backup/hyperv/required_permissions.html?ver=120
Dealing entirely with admin-enabled accounts, and actually using the Administrator account to ensure that as a troubleshooting step to no avail.
I just turned down UAC in the GUI and in the registry, restarted the hypervisor, and still can’t connect Veeam to it. On the Veeam server, the administrator credentials connect to the hypervisor through Hyper-V manager. This is starting to feel like a Veeam problem, as the creds and security seem verified.
Dealing entirely with admin-enabled accounts, and actually using the Administrator account to ensure that as a troubleshooting step to no avail.
I just turned down UAC in the GUI and in the registry, restarted the hypervisor, and still can’t connect Veeam to it. On the Veeam server, the administrator credentials connect to the hypervisor through Hyper-V manager. This is starting to feel like a Veeam problem, as the creds and security seem verified.
Might suggest opening a Support case and then posting in the forums as well for further help - https://forums.veeam.com
Got it fixed with the help of Veeam support.
In 2022 there was a MS update that hardened DCOM security. It started out as disabled by default, then it turned into being enabled by default with a reg key you could implement to bypass it. In March of 2023, an update enforced it. This DCOM hardening was preventing the non-domain-joined Veeam server from passing the target server’s local admin credentials through to join it to the backup infrastructure.
Further details: KB4376: Access to Hyper-V or Veeam B&R Components Fails After DCOM Hardening is Enabled
The resolution is to install Microsoft KB 5005102 on the Veeam server: Microsoft Update Catalog
This information was really hard to come by, so I hope this makes it easier for the next person to resolve their issue. This KB does not get applied through normal monthly updates, so simply patching the server will not help.
Thanks everyone for your input along the way!
Got it fixed with the help of Veeam support.
In 2022 there was a MS update that hardened DCOM security. It started out as disabled by default, then it turned into being enabled by default with a reg key you could implement to bypass it. In March of 2023, an update enforced it. This DCOM hardening was preventing the non-domain-joined Veeam server from passing the target server’s local admin credentials through to join it to the backup infrastructure.
Further details: KB4376: Access to Hyper-V or Veeam B&R Components Fails After DCOM Hardening is Enabled
The resolution is to install Microsoft KB 5005102 on the Veeam server: Microsoft Update Catalog
This information was really hard to come by, so I hope this makes it easier for the next person to resolve their issue. This KB does not get applied through normal monthly updates, so simply patching the server will not help.
Thanks everyone for your input along the way!
Glad to hear you were able to get it fixed and posted the solution.