reset all network settings of Azure Stack HCI

Hi @KA SAN CHAN ,

Sconfig is meant to be used for getting the base config done within the OS. From there on, it's best to use Windows Admin Center or PowerShell when possible. That said, I do agree it is strange you are getting a DHCP error in Sconfig when the interface you are attempting to configure was already set statically. I'll do some testing in my local lab and see if I can reproduce those results.

As you noted, there is no way to change the management IP within the cluster creation wizard itself. That is because Windows Admin Center expects communication to the nodes to be uninterrupted. Changing the IP address would certainly interrupt that flow. However, you can manage the node's IP address within WAC if you access the node directly. On the 'All Connections' page, choose Add -> Servers if your cluster nodes are not already added in the list. Then click on the node you want to change in the list. In the 'Tools' pane on the left, scroll down until you see 'Networks'. Click on this. You should see the interfaces populate in the right pane. Click on any of the interfaces to select it, then click 'Settings'. You should now be able to change the IP address. Note that because you are changing the IP address of the management interface Windows Admin Center is using, you may lose connectivity to the node temporarily and need to reconnect. If the nodes you are using are physical, be sure you have an alternate means to connect (such as idrac or ilo) just in case.

As for resetting the NICs, there are a couple of different ways you can approach it. If you wanted to reset ALL of the interfaces, you could use the old netsh int ipv4 reset command. After running this command, you would need to reboot the node for the changes to take effect.

If you want to just remove the IP settings from one of the NICs, you could do that from PowerShell without needing a reboot. Below are some examples of cmdlets you can use.

This cmdlet would remove ONLY the IP address from the adapter.
Get-NetIPAddress -IPAddress 10.220.4.167 | Remove-NetIPAddress

This cmdlet would remove the default gateway assigned to the NIC named "Management Physical 1".
Get-NetAdapter -Name "Management Physical 1" | Remove-NetRoute -NextHop 10.220.4.254

If needed, this cmdlet would reset the DNS server addresses assigned to the NIC named "Management Physical 1".
Get-NetAdapter -Name "Management Physical 1" | Set-DnsClientServerAddress -ResetServerAddress

This cmdlet would assign a new IP address, subnet mask and default gateway to the NIC named "Management Physical 1".
Get-NetAdapter "Management" | New-NetIPAddress -IPAddress 192.168.171.175 -PrefixLength 24 -DefaultGateway 192.168.171.254

This cmdlet would assign new DNS server addresses to the NIC named "Management Physical 1".
Get-NetAdapter "Management" | Set-DnsClientServerAddress -ServerAddresses ("10.220.4.108, 1.1.1.1")

There is one thing about the DNS server addresses that I would like to point out. I would strongly recommend NOT assigning any external DNS servers to any of your HCI nodes. The reason for this is because if these external servers were queried for any of your internal names, this would fail. And to DNS, any answer (even a failed query) is a successful answer. The better way to do this would be to set up your DNS server with a forwarder that has these external addresses and have your internal clients only pointing to internal DNS servers. This would allow them to still be able to resolve external names when needed, but it would be done via the DNS server itself.

Hope this helps!
Trent

Hi @KA SAN CHAN ,

With this setup, here is what I would recommend.

1. Assign both management NICs with their respective IP addresses, subnet masks, default gateways and DNS servers. The management NICs are typically the only NICs that need connectivity to nodes that would be off the local subnet, so this is where you should assign gateways. Typically, I wouldn't recommend assigning default gateways to multiple NICs, but in this case doing so will allow the management NICs to be teamed in the Cluster Creation Wizard in Windows Admin Center. Once the NICs are teamed in a SET switch, WAC will create a single virtual NIC off this switch which the host will then use for communication over the management NIC. The end result would be the host would be using only a single IP address. If you weren't looking to team the management NICs, then I would only assign the IP information to one of the NICs.
2. Assign the storage NICs with their respective IP addresses and subnet masks, but do not assign a default gateway or DNS server address. These NICs should be dedicated to storage traffic, so there is no need for these NICs to have gateways or perform DNS lookups. And since you have dedicated NICs for storage, I wouldn't team these NICs. One thing to note here is that if this were a production environment, I would recommend using separate networks for storage (i.e. put NIC05 on each node on one network and NIC06 on a second network). This is due to how SMB multichannel works and ensuring the NICs are used in their fullest capacity. But overall, it's not a requirement.
3. Technically speaking, you don't need to assign any IP information to the compute NICs, but you can if you want. The reason for this is because when you create your compute switch in Windows Admin Center, the only thing WAC tests is connectivity between those NICs before creating a SET virtual switch on top of them. So even leaving these NICs with an APIPA address (the 169.254 address you get when DHCP isn't working), I've still be able to create a compute switch without issues. As soon as the SET switch is created with these NICs, the TCP/IP stack is unbound from the NIC meaning that they no longer have any IP address assigned to them (they won't even show up when running ipconfig on your host, but you can see them if you run Get-NetAdapter). And because this switch would be dedicated for compute traffic, the host itself wouldn't have any need to have a virtual NIC shared with this SET switch. This means that the only thing communicating across this switch would be the VMs themselves, so they would need IP addresses, subnet masks, default gateways and DNS server addresses on their respective network(s).

Hope this helps!
Trent

Thank you for your information.

I have many times to create management teaming with 2 adapters but not success.
It is quick and easy to pass the create management interface step if I select 1 adapter only.
To simplify the test, I try to create converged network to include all adapters.
All network interfaces are configured with static IP address with internal gateway and internal DNS before configure at WAC.

After select the management adapter and create converged switch on WAC, a virtual switch "ConvergedSwitch" will be created on both nodes, the following adapters will be added into the vSwitch:

• the management adapter with the IP address without creating "Hyper-V Virtual Ethernet Adapter"
• the second adapter IP address setting will be cleared but the settings are move to "Hyper-V Virtual Ethernet Adapter" named "SMBv2" with that static IP address and gateway IP without DNS IP
• the third adapter IP address setting will be cleared but the settings are move to "Hyper-V Virtual Ethernet Adapter" named "SMBv1" with that static IP address and gateway IP without DNS IP

However, the nodes seems not able to communicate with each others with the error "not reachable from" xxx.xxx.xxx.xxx "using UDP on port 3343"
I can ping the management interface IP address from the node to another node but not for tIP addresses of the "SMBv1" and "SMBv2" Hyper-V Virtual Ethernet Adapter.

Only Node itself can ping its own IP addresses for all management, SMBv1 and SMBv2 adapters.

I try to disable the Windows Firewall profiles (Domain, Private, Public) to rerun the connectivity test, it will still show the same message.
Thank you.