I know the pain. You've spent hours setting up Windows Failover Clustering, ran through the validation wizard twice, and the cluster still refuses to form. The error message says something vague like "Cluster service failed to bring the cluster network name resource online" or just hangs at 60%. Let's fix it.
The Real Fix: Open These Ports
What's actually happening here is the cluster nodes can't see each other because Windows Firewall blocks the required communication. The validation wizard often passes because it uses ICMP ping, which is allowed by default, but the cluster itself needs actual TCP ports.
Run this PowerShell on every node in the cluster (run as Administrator):
New-NetFirewallRule -DisplayName "SQL Cluster Ports" -Direction Inbound -Protocol TCP -LocalPort 5022,3343,135,49152-65535 -Action Allow
New-NetFirewallRule -DisplayName "SQL Cluster Ports Out" -Direction Outbound -Protocol TCP -LocalPort 5022,3343,135,49152-65535 -Action AllowThen restart the Cluster service on all nodes:
Restart-Service -Name ClusSvc -ForceNow try forming the cluster again. I bet it works.
Why This Fixes It
The cluster uses several ports. Port 5022 is for SQL Server availability group communication. Port 3343 is for Cluster Network Driver (NetFT). Port 135 is for RPC endpoint mapper. The 49152-65535 range covers dynamic RPC ports that the cluster and SQL Server grab at random. Block any of those and the cluster nodes can't establish a heartbeat or negotiate ownership.
The validation wizard only tests basic network connectivity (ping and SMB). It doesn't test the specific ports the cluster needs to form. That's why everything looks green in validation but the cluster creation bombs out at the last step.
Less Common Variations
1. Forgot to Register the Cluster Name in DNS
Even if the ports are open, the cluster name must resolve in DNS. Check your DNS server. You need an A record for the cluster name pointing to the cluster IP (the one you assigned during creation). Without it, the cluster network name resource fails to come online.
2. IPv6 Is Enabled but Misconfigured
Some environments disable IPv6 thinking it speeds things up. Don't do that. The cluster relies on IPv6 for certain internal operations. If you must disable it, disable it fully on all nodes through NIC properties and registry. Partial disable causes random failures.
3. Antivirus Blocking Cluster Traffic
I've seen McAfee and Symantec block cluster heartbeat packets even with Windows Firewall open. Add exceptions for the Cluster service executable (C:\Windows\Cluster\clussvc.exe) and the SQL Server executable (C:\Program Files\Microsoft SQL Server\MSSQLXX.MSSQLSERVER\MSSQL\Binn\sqlservr.exe).
Prevention: Don't Repeat This
Before You Build the Next Cluster
Create a PowerShell script with all firewall rules and run it on every node before you even start the Failover Cluster Manager. I keep this in my deployment toolkit:
$nodes = @("Node1", "Node2", "Node3")
foreach ($node in $nodes) {
Invoke-Command -ComputerName $node -ScriptBlock {
New-NetFirewallRule -DisplayName "SQL Cluster" -Direction Inbound -Protocol TCP -LocalPort 5022,3343 -Action Allow
New-NetFirewallRule -DisplayName "SQL Cluster RPC" -Direction Inbound -Protocol TCP -LocalPort 135 -Action Allow
New-NetFirewallRule -DisplayName "SQL Cluster Dynamic" -Direction Inbound -Protocol TCP -LocalPort 49152-65535 -Action Allow
}
}Validate the Right Things
Don't trust the default validation. Run a custom validation that specifically tests for open ports. Use Test-NetConnection on each port between nodes:
Test-NetConnection -ComputerName Node2 -Port 5022
Test-NetConnection -ComputerName Node2 -Port 3343If any of those fail, the cluster won't form. Period.
Keep a Checklist
Firewall open, DNS record exists, IPv6 enabled, antivirus has exceptions. Check these before you click "Create Cluster". Saves you 30 minutes of head-scratching.
That's it. The cluster forms, resources come online, and you can move on to actually deploying your databases.