Hyper-V Core 2016: Building A Workgroup Cluster – Part 3, Security Setup

Windows Server 2016 features workgroup cluster support. In Part 3, I’ll give an overview of the required security adjustments you’ll need to make on your hosts and admin PC to get everyone to play nice.

Hyper-V Core 2016: Workgroup Cluster Series

Hyper-V Core 2016: Building A Workgroup Cluster – Part 1

Hyper-V Core 2016: Building A Workgroup Cluster – Part 2, Hardware

Hyper-V Core 2016: Building A Workgroup Cluster – Part 3, Security Setup

Hyper-V Core 2016: Building A Workgroup Cluster – Part 4, Cluster Setup

Hyper-V Hosts


  1. Obtain your OS image, either of the two options:
  2. Install, either to bare metal or new VMs
  3. On first boot, set your admin password. Make this the same on both nodes; required for ease of remote mgmt later.
  4. Enable Remote Desktop, set date/time, download updates.
  5. For ease of setup, consider turning off the Windows Firewall temporarily. From the Command Prompt window, type ‘powershell’ then:
     netsh advfirewall set allprofiles state off
  6. If you’re leaving the firewall enabled, punch a few holes:
    netsh firewall set service RemoteAdmin enable
    netsh advfirewall firewall set rule group="Windows Management Instrumentation (WMI)" new enable=yes
  7. Rename each host (HYPERV1, HYPERV2), join to your existing WORKGROUP (or create a new one?), and reboot.
  8. Verify you can now use Remote Desktop Connections to access each host.
  9. Open the Powershell prompt and enable Powershell remote access:
    Enable-PSRemoting -force

Configure DNS Suffix:

Workgroup clusters require that nodes utilize a DNS suffix, I assume to fake some of the requirements satisfied by normally having an AD domain.

  1. Determine a DNS Suffix you’ll use (eg, fugelnet.local)
  2. Set these items in the registry and in DNS, from the Powershell prompt:
    Set-ItemProperty "HKLM:\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\" -Name Domain -Value fugelnet.local
    Set-ItemProperty "HKLM:\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\" -Name "NV Domain" -Value fugelnet.local
    Set-DnsClientGlobalSetting -SuffixSearchList fugelnet.local
  3. Verify your new values:
    get-ItemProperty "HKLM:\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\"

Configure WSMan:

  1. Now we need to configure WSMan, which is responsible for Windows Remote Management operations sessions. I tried this by explicitly naming all nodes in the TRUSTEDHOSTS item, but didn’t see proper authentication until I replaced the node names with a * (not great security). This could have been a formatting issue. Run these from Powershell prompt on BOTH nodes AND your management PC:
     set-item wsman:\localhost\client\trustedhosts -value "HYPERV1.fugelnetlocal,HYPERV2.fugelnet.local"
  2. You may receive an error “ACCESS DENIED” here. If this happens, try:
    stop-service WinRM
    start-service WinRM
    1. Reboot, if it still errors. This cleared the error for me.
    2. Enable PSRemoting if you haven’t already (step 9 under “BUILD”)
  3. Verify your new value:
    get-item wsman:\localhost\client\trustedhosts

Configure HOSTS files:

  1. At this point, we need to know what you’re calling your cluster. Pick a name and stick to it.
  2. Identify the IP addresses of your hosts (I’m doing DHCP reservations at my router so I don’t have to set static IPs, but there’s Powershell out there to do this). Identify the IP you’ll use for your Cluster IP too.
  3. From a command prompt (‘exit’ if you’re still at the PS prompt on your hosts), run these to add HOSTS entries for the servername+DNS-Suffix naming scheme required for workgroup clustering. Update to use your own hostnames, DNS suffix, and IP addresses
  4. Set file="%windir%\System32\drivers\etc\hosts"
    echo HYPERV1 >%file%
    echo HYPERV1.fugelnet.local >> %file%
    echo HYPERV2 >>  %file%
    echo HYPERV2.fugelnet.local >> %file%
    echo HYPERVCLUSTER >> %file%
    echo HYPERVCLUSTER.fugelnet.local >> %file%
  5. Repeat STEP 4 on BOTH NODES as well as your MANAGEMENT PC. I had an issue later connecting to my cluster until I had every possible permutation, including the cluster name, added to HOSTS.

Management PC

Install Hyper-V and RSAT Tools:

  1. Hyper-V Manager: Consult these instructions from Microsoft 
  2. Remote Server Administration Tools – Windows 10: download here

Configure Component Services:

Per this helpful blog post, we should also adjust some access permissions within Component Services to allow our management tools to get connected.

  1. Run ‘dcomcnfg.exe’
  2. Browse to Computers, right-click My Computer
  3. Select COM security, Access Permissions > Edit Limits

Configure CredSSP:

This step isn’t required to create a workgroup cluster, but rather is required to manage it. CredSSP provides an encrypted path for sending remote credentials. This allows the local Hyper-V Management Tools to connect to a remote Hyper-V host without domain authentication. Credit due in full to this blog post for providing another piece to this puzzle.

  1. From each Hyper-V host, run from the PS prompt:
     Enable-WSManCredSSP -Role Server -Force
  2. Connect to your management PC (this can be either Windows Server or Windows 10) and launch gpedit.msc
  3. Computer Configuration > Administrative Templates > System > Credentials Delegation
  4. Modify  “Allow delegating fresh credentials with NTLM-only server authentication
  5. Select Enable, then click SHOW button
  6. In VALUES, enter all possible permutation of host names, click OK and OK

When connecting to your individual hosts via the Hyper-V Manager tool, you’ll choose “connect as another user”. Enter the local administrator credentials for that host, then you’ll get a prompt to “enable delegation of user credentials”, which will leverage CredSSP. Choose YES and you should be connected.

What’s Next

Now that we have our nodes up and ready to rock, in Part 4, I’ll outline the process for creating the cluster.


3 thoughts on “Hyper-V Core 2016: Building A Workgroup Cluster – Part 3, Security Setup

  1. i try yo use this for 2 hyper-v servers ( with gui ) . i can manage from 1 to another, but when trying to replicate it says that it can’t because of failed kerberos authentication


    • If you’re doing a live migration, I experience the same behavior. You’ll need to be domain joined for that to work. Best option is to just use quick migration which works without issue.


  2. I don’t try live migration. It already failed by enabling replication. It says hyper-v failed to authenticate the replica server ….. using kerberos authentication. No credentials are available in the security package


What would you like to say?

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s