It’s about making an enhancement on the new feature ManagementPointNetworkType introduced in RS3 which will improve Cluster Connectivity from the behavior what we see today.

History: Until RS3, this wasn’t configurable & the cluster’s CNO will be what’s created using MPNT as Singleton. RS3 onwards this can be set as Distributed.
You’ll ask: What's the difference?
A CNO of type Singleton needs an IP address while the Distributed ones don’t. This is a boon for the AZURE based WSFC deployments, which are currently using 169.254.x.y and are useless for any remote connections or anything but taking space in AD otherwise in all cases eating an IP address.

                            When we create a Cluster with CNO type of Distributed instead of Singleton, the benefits are;

• Remote Cluster Access
• Remote PerfMon
• RDP
• Ping tests etc…
• Save an IP Resource
• Get rid of NetBIOS
All the above ‘ve been tested & go well.

My ask from MS  This CNO (resource) property isn’t switchable. Once a cluster is created using either a Singleton (Network Name) or Distributed (Distributed Network Name) type it can’t be swapped. Please make amendments so we can flip-flop.
Where it’ll help?

            Cluster migrations from On-Prem to Azure by keeping the relocated CNO usable (which currently aren’t).

            Here’s a nebulous illustration for Migrating an On-Prem SQL AOAG  to Cloud.

Sequence of steps…
Cluster Node Name  N1 N2 aN1 aN2
Starting with an on-prem solution consisting of two nodes.
• CNO (type singleton / Network Name) is remotely accessible, for its based upon a usable IP Address. CNO is accessible
Extending the WSFC to AZURE for it will be finally migrated there.
• Add an additional IP Resource as dependency under CNO and assign a link-local IP (169.254.x.y) to the Cluster’s Network Name for AZURE Network’s Subnet.
• As a side effect when the CORE RES GRP is on aN1/2 the WSFC CAP can’t be used for operations & one has to use a LIVE NODE name. CNO is accessible using the On-Prem IP
Remove the On-Prem Nodes thus leaving the Cluster Network names based on the link local IP only.
• At this point CNO, hosted over 169.254.x.y isn’t usable. CNO isn’t accessible.
What I’m asking is a feature addition to Flip the CNO type to Distributed. CNO is accessible
By the end, if the CNO type can be changed (type Distributed) it will be remotely accessible & available for usage. This will certainly benefit all.
The command-lets Remove-ClusterNameAccount & New-ClusterNameAccount are useful when migrating a cluster between domains. Incorporating the above in this command will do the job. This will also help in migration testing by doing flips before permanent settlement.

Here under are few snaps to illustrate.
1. CNO & dependent resources.
a. As created today.

b. Where ManagementPointNetworkType is set as DNN. Saves you from the perils of setting & living with dead load of 169.

1. Cluster CNO Properties for AZURE based VMs.
   Current - Singleton RS3 – Distributed.

Summary: WSFC builds on Azure using release RS3 onwards will automatically use ManagementPointNetworkType set as DNN. Both on-prem & in Azure this can be set to be created otherwise as well NN / DNN (CLI) but it can’t be changed.

                                 My ask is a feature so users can change (ManagementPointNetworkType between NN & DNN).


            Comment your say on this & Please vote, for the migrated CNO (on-prem to Azure) will be usable this time.