Cluster Group Not Available (0X00001394) – Quick Fixes

What Actually Triggers 0X00001394

I've seen this error more times than I can count. Last month a client running a two-node Windows Server 2016 cluster for their SQL Server had it pop up after a power flicker. One node rebooted, the other stayed up, but the cluster group that held the SQL instance just vanished from management tools. Any attempt to bring it online got 0X00001394 – the group wasn't available for any new requests.

The core issue is always the same: the cluster lost quorum, a node is in a weird state, or the group itself is stuck. You'll usually see this in Failover Cluster Manager or when running Get-ClusterGroup in PowerShell. The group shows Offline or Failed and won't budge.

Cause #1: Quorum Loss or Witness Failure

This is the most common trigger. The cluster votes for who's in charge. If half the nodes can't talk to the witness (a file share or disk), quorum drops. Groups stop responding because the cluster can't decide who owns them.

Fix It

1. Check quorum health. Open PowerShell as admin and run:

Get-ClusterQuorum
Get-ClusterNode | Select-Object Name, State, NodeWeight

If any node has NodeWeight = 0 or shows State = Down, that's your problem. Had a client last month whose file share witness went offline due to a NAS firmware update – all nodes looked fine but quorum was lost because the witness was unreachable.

2. Force quorum on the surviving node. If a node is down and won't come back, start the cluster on the good node with the /fq switch:

net start clussvc /fq

This forces the node to form a quorum with itself. Then you can evict the dead node later.

3. Validate witness connectivity. For a file share witness, test by browsing to it from each node. For a disk witness, run Get-ClusterResource and see if the disk shows Online.

Once quorum is stable, the group should come back on its own. If not, run:

Get-ClusterGroup -Name "YourGroupName" | Start-ClusterGroup

If that errors out, move to Cause #2.

Cause #2: Stale Node or Cluster Service Hung

Sometimes the cluster service on a node is running but not responding to heartbeats. The node shows Up in Failover Cluster Manager but can't actually communicate. This leaves groups in a limbo state.

Fix It

1. Check cluster service state. On each node, run:

Get-Service -Name ClusSvc | Select-Object Status
Get-ClusterNode

If a node shows Status = Running but Get-ClusterNode reports it as Down, the service is hung.

2. Restart the cluster service. On the problematic node, run:

Restart-Service -Name ClusSvc -Force

I've had to do this on nodes where the cluster log was filled with ERROR_GROUP_NOT_AVAILABLE entries. A restart flushes the stale state. Wait 30 seconds, then check Get-ClusterNode again.

3. Check cluster logs. If the restart doesn't work, look at the cluster log on that node:

Get-ClusterLog -Destination C:\ClusterLogs

Search for 0x1394 or GROUP_NOT_AVAILABLE. I once found a bug in the Hyper-V role on a 2019 node that caused this – a CU update fixed it.

Cause #3: Group Resource Stuck in Pending State

This is rarer but happens when a resource inside the group (like an IP address or disk) can't complete its online/offline sequence. The group itself locks up.

Fix It

1. Identify the stuck resource. Run:

Get-ClusterGroup -Name "YourGroupName" | Get-ClusterResource | Select-Object Name, State

Look for any resource in Pending or Failed state.

2. Force the resource offline. Take the resource offline individually:

Get-ClusterResource -Name "StuckResourceName" | Stop-ClusterResource -IgnoreLocked

Then bring it back online:

Start-ClusterResource -Name "StuckResourceName"

3. If that doesn't work, evict and re-add the resource. This is drastic but works. Delete the resource (don't delete the group), then add it back via Failover Cluster Manager. I've done this for IP address resources that wouldn't release their lease.

One time, a client's SQL Server group had a Client Access Point resource stuck because DNS registration was timing out. I deleted the resource, re-created it with a static IP, and the group came alive instantly.

Quick-Reference Summary Table

Don't overthink this error. Nine times out of ten, it's quorum. Check that first, then move down the list. You'll have that group back online in minutes.