[RESOLVED] Failed to connect Hyper-V standalone

[Easy-Works]

Case #03723259

I'm getting failed to connect to host LANIP Access Denied or timeout expired.
Check if you have local administrator privileges on computer LANIP.
Possible reasons:
1. Invalid Credentials.
2. Specified host is not a Hyper-V server.

The scenario I have is a Windows Server 2012R2 Standard running Hyper-V (not attached to a domain). I have VM setup with Server 2016 Standard that I've installed Veeam Backup and Replication Community Edition. After I open VBR go to backup infrastructure > add server > Microsoft Hyper-V > Hyper-V then It ask for the DNS name or IP which I input the LANIP > Choose Microsoft Hyper-V server (Standalone) > added the administrator credentials for the Hyper-V Host 2012R2 (i've tried both servername\administrator and just administrator) but i get the error above. I've tried turning off the windows firewall but still get the same message. I don't have to install a Veeam agent on the Hyper-V host do i? Side note at 1 time there was a hyper-V management or something like that in the programs/features on the Host which I uninstalled hoping maybe that was the issue and it would just re-add it.

[terike]

I have the same issue - how did you solve it?

[wishr]

Hi Terike,

Welcome to Veeam Community Forums and thanks for posting.

The original issue has been resolved by disabling UAC on the server and rebooting it because it was not joined the domain.

Thanks

[annc]

Support case ID: 03882994

Hi,

Clean install of:
- physical machine - Windows 2019 Standard, standalone (non-domain), for Hyper-V Virtualization with Hyper-V role installed
- VM (Hyper-V) - Windows 2019 Standard, standalone (non-domain) - for Veeam Community, latest version
- VM (MSSQL 2016) - Windows 2019 Standard, standalone (non-domain) - for DBs, also for Veeam's DB
- many other Windows & Linux VMs running on Hyper-V

I'm trying to add physical machine (with Hyper-V role and many VMs) to Veeam Managed Servers, and it fails with error:

"Failed to connect to host XXX. Access denied or timeout expired. Check if you have local administrator privileges on computer XXX. Possible reasons: 1. Invalid credentials, 2. Specified host is not a Hyper-V Server".

No matter which account I use (local "Administrator" or other user with Administrator rights). It fails using IP address and hostname as well (which is resolved for example by ping). Windows Firewall is disabled.

When I try add that same macihne as a standard Windows host (non Microsoft Hyper-V) - it works without any problem.

Veeam Community Edition is latest version, all of the Windows system are up-to-date (Windows Update done).
Polish version of Windowses (I don't know is it matter or not)

What I'm doing wrong and what should I do?

[foggy]

Please review the thread above, should give you a hint.

[annc]

Disabling UAC is very weird. This security option, build in each version of Windows should be always enable. Do you mean that Veeam works only on hosts with disabled UAC?

Thanks god I didn't bought full license yet. In my opinion - it's huge security hole. Thanks for help - I'm looking for other software, which doesn't need such weird things.

[wishr]

Hi Annc,

Please let me clarify. The use of local accounts for remote access is a huge security hole itself. That's why UAC blocks such remote connections by default starting from ~2010s or maybe even earlier. It's not about Veeam or our inability to support some technology - it's about Windows OS security concepts and how they are implemented on the OS and environment layers.

If you would like to start moving towards securing your environment I'd suggest the following:
1. Put your Hyper-V servers and other important infra onto a domain;
2. Consider using LAPS or disable remote access for local accounts completely;
3. Move B&R server off the domain, configure the repository to go offline when not in use;
4. Follow the 3-2-1 rule.

Hope it makes sense. Thanks.

[foggy]

I'd also add that this is actually not a Veeam-specific but a general remote WMI connection specific issue, so you will hardly find another software that will work as you expect with this setup. If the server was in the domain and a built-in domain administrator account was used (which is exempt from UAC), you wouldn't have encountered any issues.

Here's another reading on that.

[nmdange]

Disabling UAC on servers is not unusual, see https://support.microsoft.com/en-us/hel ... ows-server

Also UAC doesn't even exist on Server Core, so following Microsoft's recommendation to run Hyper-V on Core means you wouldn't be able to enable UAC even if you wanted to.

[AlexHeylin]

My £0.02 on this - Don't tell us to put standalone Hyper-V servers into a domain. They're standalone in order to protect them from the domain, both Hyper-V and in many cases VBR too. In many smaller sites, there is one physical server which is the Hyper-V server, which has VBR installed to it. Ideally it's running with all inbound connections blocked by Windows firewall, and hardened as much as possible.

LAPS offers no advantage. We have a password management solution in place.

Part of the problem here is Veeam treating the local machine as remote, and trying to connect to it via the network in a scenario which won't work - when local access will.

Veeam Support - Case # 04929878

[wishr]

Hi Alex,

No one is forcing you to join certain servers into a domain. On the contrary, our recommendation has always been to have VBR sever off the domain, as stated above and in many other posts and topics. However, Windows design requires you to disable UAC in this particular case.

Regarding the connection approach, it makes sense, so this part will be treated as a feature request.

Thanks

[jo_biblio]

For informations :
To keep UAC enabled, I followed this https://www.veeam.com/kb1914

[AlexHeylin]

Thanks jo_biblio - however there should never be a requirement to use THE Administrator account. For years MS considered that account so insecure it was disabled by default on some Windows builds. Using THE Administrator account as (effectively) a backup service account breaks at least two security rules in well secured organisations.

Thanks Wishr.
Just for clarity - on Nov 27, 2019 10:11 am you said

If you would like to start moving towards securing your environment I'd suggest the following:
1. Put your Hyper-V servers and other important infra onto a domain;

MANY of our customers run one physical server which is Hyper-V with VBR installed on it. That server should be kept out of the domain and hardened as much as possible. So, no you didn't say to put the VBR server in a domain, but you did say to put the Hyper-V server(s) in a domain and in a common use case for us that's the same thing.

I realised Veeam didn't design the cause of this particular gotcha, and one really has to wonder which numpty at MS did, and how it got through QA because it seems to breach some of their own design / security guidelines.

Thanks for accepting it as a FR. In the meantime it would be sensible if the prereq docs were updated to include this gotcha - because right now (well 2 weeks ago) it just said the account had to be a member of the Administrators group, which of course the account I was using was. The prereq docs being incomplete cost me two hours on this. It's mentioned in the BP docs, but not the "manual" for the software. It seems even Veeam's own support team aren't entirely clear on this issue either.

[wishr]

Hi Alex,

Thanks for adding additional inputs.

Having a VBR server installed on top of a Hyper-V server is definitely not the most widespread usage scenario, especially across large organizations, and I can confirm we are not testing such configurations in our lab environments during QC cycles as the priority goes to enterpise-grade architectures.

Regarding technical documentation, you may leave your feedback directly to our technical writers by pressing "Send feedback" on the corresponding UG webpage.

Thanks

[HugoHew]

Hi I have the same Issue. I disabled (EnableLUA Value "0") on physical server & VM and add (LocalAccountTokenFilterPocily "1"), Port open 9395,6183 on physical server and Vm, Network Discovery on. after restart server still no luck the error still persist, any solutions on this, thank you. 

[wishr]

Hi HugoHew,

If none of the aforementioned solutions helped, we would recommend opening a support case to get it sorted. Please don't forget to post your case ID once you get it.

Thanks

[rmellonh]

Guys.

Had this problem today on 2 HV server 2016 and a Windows Server 2016.

On HV, I removed the update :
KB5014702

And on Windows Server:
KB5013952
KB5014702


I noticed that whenever I ran a scan from the V&B server, on the host (HV and w2016), the logs were generated:

The server's authentication level policy does not allow the DOMAIN\Administrator SID (S-1-5-21-2782991539-1201723491-671776163-514) from address 192.168.0.251 to activate the DCOM server. Increase activation authentication level by at least RPC_C_AUTHN_LEVEL_PKT_INTEGRITY in application.


I researched something on the internet and noticed that this is caused by a change by MS in the security issue.

https://support.quest.com/en-us/kb/3351 ... erver-2019


https://support.microsoft.com/en-us/top ... 43d2-941e- 37ed901c769c


Strange is not having happened on other servers with the same settings.

Hope this helps.

[TommyCGN]

Thanks to rmellonh!

With his advice I was able to solve the problem. With Microsoft Milestone from 14.06.2022, changes were made over all upcoming security updates that result in this error. In our case, the backup of VMs in Hyper-V. Identifiable via the server log and messages like this:

The server-side authentication level policy does not allow the user ***\Administrator SID (S-1-5-21-1950550814-1681971570-579455201-500) from address 192.168.*** to activate DCOM server. Please raise the activation authentication level at least to RPC_C_AUTHN_LEVEL_PKT_INTEGRITY in client application.

The problem can at least be postponed until 2023 via a change in the registry:

https://support.microsoft.com/en-us/top ... ed901c769c

Good luck!

[Moopere]

@rmellonh, thank you, this is the solution.

Bit of a worry that the registry work-around isn't going to work any longer after MAR 2023 ... only 6 months away!

Having done some google-foo after reading this post the problem is hitting people everywhere - mostly in monitoring and logging. I wonder if the previous MS patches are time bombed or whether a future patch will be required to make the hardening mandatory?

I can't see the sense in making it mandatory myself - make it default sure, but mandatory? No case for that. Those with difficulties due to unpatched software will simply be forced to not patch their servers.

[rz7k9l]

I installed a new hyperv 2019. ik never had issues with hyperv 2016 to connect to from Veeam. Hyperv and veeam are in workgroup.
I changed the winrm settings so i can manage the hyperv form my veeam server sith Server Manager, i can connect with WMI..

but i cannot connect to hyperv form veeam to backup the virtual machines.
latest version veaam community edition.
UAC disabled as well as firewall (for test)

any help would be appreciated.
regards,

[Moopere]

@rz7k9l: The connection problem being described in this thread is very specific and generates a log entry like this:

"The server's authentication level policy does not allow the DOMAIN\Administrator SID (S-1-5-21-2782991539-1201723491-671776163-514) from address 192.168.0.251 to activate the DCOM server. Increase activation authentication level by at least RPC_C_AUTHN_LEVEL_PKT_INTEGRITY in application."

The problem relates to this:

https://support.quest.com/en-us/kb/3351 ... erver-2019
https://support.microsoft.com/en-us/top ... ed901c769c

If you are getting this specific error the registry based workaround will fix it until you patch Windows/Server in MAR/APR.

If you are getting a different error I'd suggest a different/new thread.

[mihoo]

I have connection problem after windows update
At https://support.microsoft.com/en-us/top ... c141-43d2- 941e-37ed901c769c is information that there is no option to disable. How to get around this problem.

[doktornotor]

Remove that update or join the machine to domain.

[mihoo]

doctornotor exactly how to do it, elaborate and everything works

[diwa]

I'm getting the error descriped by Moopere.
At our enviorment, Hyper-V and VBR are within the domain.
I am running VBR as a domain admin, which I also add to the Hyper-Vs local admin group.

[info@awacomng.com]

it simple just run windows Update on both the VBR and the HYPER V server should fix this error.

[anaputnam]

1. Disable UAC on Hyper-V hosts (in a cluster or standalone).
2. Use the local Administrator account from/on the Hyper-V in the Veeam wizard to connect to HyperV. No other local accounts will work.
https://www.veeam.com/kb1914

[zechorieus]

Hi Terike,

Welcome to Veeam Community Forums and thanks for posting.

The original issue has been resolved by disabling UAC on the server and rebooting it because it was not joined the domain.

Thanks

Hi
I did this and it still failed.
What other measures can be carried out?

[leoness]

You can try to type username like this when you add host to veeam inventory. -> HYPERVHOSTNAME\Administrator