Fix ERROR_CLUSTER_NO_NET_ADAPTERS (0X00001712)

The Real Fix: Check Network Bindings and Driver Versions

You're setting up a Failover Cluster and you get ERROR_CLUSTER_NO_NET_ADAPTERS (0X00001712). The cluster service can't find any usable adapters. Don't tear your hair out over hardware—99% of the time the adapters are fine, they're just not visible to the cluster.

Here's what you do:

Open an elevated PowerShell or CMD on each node that's failing.
List all network adapters with:
```
Get-NetAdapter | Where-Object {$_.Status -eq 'Up'}
```
If you see adapters here, the hardware works. If not, check physical connections and driver installation.
Check that the cluster service sees them:
```
Get-ClusterNetwork
```
If this returns nothing or an error, the service doesn't know about the adapters.
Force the cluster to rediscover adapters:
```
Stop-Service ClusSvc
    Start-Service ClusSvc
```
Wait 30 seconds, then run Get-ClusterNetwork again.
Still nothing? Check the network adapter's binding order. The cluster only sees adapters that have the Client for Microsoft Networks and File and Printer Sharing for Microsoft Networks checked. Run:
```
Get-NetAdapterBinding -ComponentID ms_msclient, ms_server
```
If these are disabled (Enabled: False), enable them with:
```
Enable-NetAdapterBinding -Name "YourAdapterName" -ComponentID ms_msclient
    Enable-NetAdapterBinding -Name "YourAdapterName" -ComponentID ms_server
```
Then restart the cluster service again.
If that doesn't do it, update the network driver. I've seen this most often on Broadcom NetXtreme and Intel PRO/1000 adapters on Server 2016 and 2019 with old drivers. Download the latest manufacturer driver (not Windows Update), uninstall the current driver from Device Manager, reboot, then install the new one.

That's the fix for 9 out of 10 cases. If you're still stuck, read the next section.

Why This Works

The cluster service (ClusSvc) doesn't see raw hardware—it sees network adapters through the Windows networking stack. What's actually happening here is the cluster queries the Network List Manager (NLM) for available interfaces. The NLM only reports adapters that are:

In the Up state (not disabled, not disconnected).
Have an IP address assigned (IPv4 or IPv6).
Have the required network bindings enabled (ms_msclient and ms_server).

If any of these conditions fail, the adapter is invisible to the cluster. The driver update fixes cases where the adapter registers itself incorrectly with the NLM. Restarting the cluster service forces a fresh enumeration of adapters from the OS, which clears any cached state.

The reason step 3 works (restarting ClusSvc) is that the cluster caches adapter info at service start. If an adapter was disconnected when the service started, it won't be seen even after the cable is plugged back in. Restarting forces a re-scan.

Less Common Variations

Variation A: Virtual Adapters in Hyper-V or VMware

If you're running the cluster on VMs, you might see this error when the virtual switch misconfigures the adapter. On Hyper-V, the fix is:

Set the virtual adapter to Static MAC address (don't let it change on reboot).
Disable SR-IOV on the VM's network adapter—cluster doesn't play well with it.
Make sure the virtual switch is External, not Internal or Private.

Variation B: Multiple Adapters, Cluster Picks the Wrong One

This error can also pop up if the cluster sees adapters but none of them are marked as usable for cluster communication. Run:

Get-ClusterNetwork | Select-Object Name, Role, Metric

If adapters show up but their role is 0 (disabled for cluster), you need to set at least two adapters to Cluster communications only (role 1) or Client and cluster communications (role 3). Use:

(Get-ClusterNetwork -Name "YourNetworkName").Role = 1

Variation C: IPv6 Disabled

On Server 2012 R2 and earlier, disabling IPv6 could cause this error. The cluster needs at least one adapter with IPv6 enabled (even if you don't use it) to build the adjacency list. Re-enable IPv6 on the cluster network adapter in Network Connections.

Prevention

Before you create a new cluster, do this:

Run the Validate a Configuration wizard in Failover Cluster Manager. It'll catch adapter visibility issues early.
Keep network drivers at the same version across all nodes. Mixing OEM driver versions is a common cause.
Don't disable IPv6 on any adapter that the cluster will use. Yes, it's annoying, but the cluster stack relies on it for neighbor discovery.
Set a static IP address on every cluster network adapter. DHCP leases expiring mid-operation will cause temporary invisible adapters.
Document your network binding order. If you ever change it (e.g., adding a new NIC), the cluster might lose sight of the adapters until you restart the service.

That's it. The error is almost never hardware failure—it's always something hiding the adapter from the cluster's view. Check bindings, drivers, and service state, and you'll be up in minutes.