Azure Stack HCI Test Build - Can no longer Progress further then "Select management adapters"

Hello,

Configuring an Azure Stack HCI cluster via Windows Admin Center requires at least one dedicated NIC for management purposes and at least one NIC that can be used for cluster communication (though two or more are recommended for redundancy). The machine from which you are configuring the cluster must have continuous connectivity to the management NIC throughout the entire setup process as well as after. Per the screenshot above, it appears you only have one NIC total per server. While this NIC could be the management NIC, it would not leave you with a NIC that could be used for cluster connectivity. Please try adding at least two total NICs per server and see if you can then choose your management NIC. Let us know if you have any additional questions.

Thanks so much!
Trent

Hey - looking at your graphic, and the speed being 4Gbps, i think WAC/AzSHCI may think you have some kind of SET switch already in place. Here's what I would do:

1) RDP to each node and clean up all virtual network remnants - remove any vSwitches and SET switches/Teams with PowerShell - likely Remove-VMSwitch, Remove-VMNetworkAdapter and Remove-VMSwitchTeamMember.
2) Ensure your Nested AzSHCI nodes have at least 2 NICs using Hyper-V Manager from your physical Hyper-V Host/WAC and ensure that at least one of those NICs has an IP address on the management network. Ideally, in a nested config, you should give the nodes 4 NICs, and dedicate 1 to management, and for simplicity, one for VM traffic, and 2 for storage traffic.
3) Then run through the WAC wizard again. WAC needs to dedicate at least one management adapter to it's use, so just choose the one that has the IP and it should work from there.

Also, were you following the Eval guide? https://github.com/Azure/AzureStackHCI-EvalGuide - if so, I'd love to understand your feedback on the quality and how we can improve it.

Let us know!

Hi - I am wondering if you are still holding on to this setup? I would like to get some more details here to investigate this further...

The only requirement for WAC to check if these adapters are available is it checks if we can start a Powershell session on them. If we can’t, there’s not a reliable way to progress through the network configuration step. Maybe there is an excluded adapter that is actually being used to connect to them by default?

I would need a .har network trace here and probably the output of “ping -4 <servername>” so we can see what ip gets resolved by default.

Here are instructions to collect the .har file
In Edge:
Step 1: Click the three dots in the upper right corner, and go to More Tools -> Developer Tools.
Step 2: Open the Network tab, and press the Play button to start recording.
Step 3: Reproduce the issue that you were experiencing.
Step 4: Press Stop when you're done, and click Save.
In Chrome:
Step 1: Select View -> Developer -> Developer Tools, and open the Network tab.
Step 2: Look for the record button, check the Preserve Logs box.
Step 3: Press the record button, and click the Clear button to clear out any existing logs.
Step 4: Reproduce the issue that you were experiencing.
Step 5: Once you have reproduced the issue, right-click anywhere on the grid of network requests, select 'Save as HAR with Content'.

Also please capture
the output of “ping -4 <servername>” on each of these nodes.

Thanks for helping us make this experience better!

The problem appears when WinRM over HTTS is selected in Windows Admin Center. In that case, WAC is unable to connect to the destination servers due to (1) a buggy certificate hostname validation (expecting an IP address where hostname is provided) and (2) a rather invalid assumption that it can connect to the destination server using an IP address any of its NICs has configured.

A workaround is to (A) disable WinRM over HTTPS in WAC and (B) enable WinRM over HTTP in

To disable WinRM over HTTPS in WAC run the following from PowerShell (run as admin):

Set-ItemProperty -path "hklm:\SOFTWARE\Microsoft\ServerManagementGateway" -name WinRMHTTPS -value 0  
Restart-Service -Name ServerManagementGateway  

To enable WinRM over HTTP, if disabled on the destination server, run the following from an admin command prompt on the destination server:

winrm create winrm/config/Listener?Address=*+Transport=HTTP  
winrm quickconfig -transport:http  
winrm enumerate winrm/config/listener  

Details from browser debugging console:

I tried this fix and I still am not able to move beyond this point. I am trying to spin up this environment using Nested Virtualization on a VMware ESXI 7.0 host.