New-HNSNetwork breaks host network on 2004 and 20H2

[mdavis77]

Issue:
When we do New-HNSNetwork with a type of overlay or l2bridge, when it drops and recreates the host nic, it loses our static IP settings. It reverts to 169.254.237.x. If we enable DHCP, then it will pick up a DHCP address and work, but we do not have DNS enabled on our backend systems networks.
If I remove the HNS Network, then the IP comes back and the node is back on the network.
It only does this when the host VM is 2004 or 20H2 from what we can tell. Our currently running 1909 systems work fine.

Steps to reproduce:
New-HNSNetwork -Type 'Overlay' -AddressPrefix '10.42.1.0/24' -Gateway '10.42.1.1' -Name "vxlan0" -SubnetPolicies @(@{Type = "VSID"; VSID = 4096; }) -Verbose
or even farther back the command chain:
$JsonString = '{
"Subnets": [
{
"GatewayAddress": "192.168.255.1",
"AddressPrefix": "192.168.255.0/30"
}
],
"NetworkAdapterName": "Ethernet2",
"Name": "External",
"Type": "l2bridge"
}'
Invoke-HnsRequest -Method POST -Type networks -Data $JsonString

Expected result:
Ethernet 2 adapter that gets recreated has the static ip settings it had before running the command

Actual result:
Ethernet 2 adapter that gets recreated is reset to dhcp and so loses network connectivity completely.

Any other info:
As said above, this is running in production in 1909. But as soon as we do this on a 2004 or 20H2 host system. All I can figure is that something must have changed in vmcompute.dll causing this, as the hns.psm1 script itself hasn't changed.

[daschott]

This should be resolved in Server 2022. Can you confirm please?

[mdavis77]

Confirmed, I setup a Server 2022 VM and I can run the above New-HNSNetwork command and it works properly, setting my static IP back to what it should be.

That definitely proves there is a bug in 2004 and 20H2. But at least we have the ability to upgrade our windows nodes and containers now to 2022.