Access Denied to Failover Cluster Manager after Windows Upgrade

Copper Contributor

I'm working on upgrading a Hyper-V Failover Cluster from Windows Server 2016 to 2019 as documented by Microsoft. (https://learn.microsoft.com/en-us/windows-server/failover-clustering/cluster-operating-system-rollin...) After upgrading the first node in the cluster to 2019, it rejoins the cluster and accepts roles and cluster volumes. However, two major issues remain:

 

1. The upgraded server is unable to host any VMs that are powered on. It reports "The virtual machine '[VM-name]' is using processor-specific features not supported on physical computer '[HV-name]'. To allow for migration of this virtual machine to physical computers with different processors, modify the virtual machine settings to limit the processor features used by the virtual machine." However, changing the setting to limit processor features does not fix it as it reports the same issue after changing it.

 

2. The upgraded server is unable to connect to the cluster in the Failover Cluster Manager as it fails with "Access is denied. (Exception from HRESULT: 0x80070005 (E_ACCESSDENIED))". I am logged in to the server with the same domain admin account that I was using before the upgrade with no issues.

 

The issue is the same as is described in this forum post but the resolution listed here did not work. (https://learn.microsoft.com/en-us/answers/questions/1076915/getting-error-hresult-0x80070005-(e-acce...)) I also tried `netsh winsock reset catalog` as suggested here (https://social.technet.microsoft.com/Forums/windowsserver/en-US/b1be178e-ae61-4a80-b880-b84b251a2d98...)

 

Also tried manually applying additional updates post-version upgrade and rebooting, manually adding domain admins to have full control of cluster, and evicting and re-adding the upgraded node to the cluster.

 

Running `Get-ClusterAccess` on both upgraded and non-upgraded nodes yield the same output.

2 Replies

@SirDoctorK 

Hi, did you get to resolve the issue ?

 

@yosiyakovi 

I still haven't been able to get a properly functional mixed-OS cluster. Instead, I have been building a new cluster on Windows 2022 and moving the cluster volumes to the new cluster. It's far from ideal as it requires downtime for the VMs and significant delays to VM replication, but it's the best I've been able to get.