0X0000139D

Fix ERROR_NOT_QUORUM_CAPABLE (0X0000139D) on Windows Failover Cluster

Server & Cloud Intermediate 👁 0 views 📅 May 26, 2026

This error hits when a disk can't hold cluster quorum. Usually a missing partition or wrong disk signature. Here's the real fix.

When Does This Error Appear?

You're building a Windows Failover Cluster on Server 2019 or 2022. You add a shared disk—maybe an iSCSI LUN or a Fibre Channel volume—and try to configure it as the quorum witness. The cluster validation wizard or PowerShell spits back:

ERROR_NOT_QUORUM_CAPABLE (0x0000139D)

This isn't a random glitch. It happens right when you assign the disk role to Quorum in Failover Cluster Manager, or when you run Set-ClusterQuorum. The disk shows up in the list of available storage, but the cluster refuses to trust it for quorum.

Root Cause

What's actually happening here is the cluster is checking whether the disk meets the requirements for holding quorum data. Windows expects the disk to have a simple NTFS partition with no special volume layouts (no dynamic disks, no mirrors, no spanned volumes). Two specific things trip this up:

  1. Missing or corrupt partition table. The disk has no valid GPT or MBR partition. Sometimes SAN admins present a LUN that's raw—no partition created yet. The cluster sees a disk with zero partitions and says "nope."
  2. Wrong disk signature. Even if there's a partition, the disk's unique signature (used by Windows to identify it) might be duplicated or missing. This happens when you clone a disk or reuse a LUN from another cluster without cleaning it first.

The reason step 3 in the fix below works is because Clean wipes the entire disk, including the signature and partition table, so you start fresh.

How to Fix It

Skip the GUI here—DiskPart does the job cleanly. You'll need to be on any node that can see the disk (but it's better to do this on the node that will own the quorum).

Step 1: Identify the problem disk

Open Disk Management (diskmgmt.msc) or run:

diskpart
list disk

Look for the disk that's meant for quorum. Its size should match the LUN you provisioned. Note the disk number (say, Disk 5).

Step 2: Check its current state

With the disk selected in DiskPart:

select disk 5
detail disk

Look for the Volume list. If it shows "No volumes" or the partition style says "RAW" instead of "GPT" or "MBR", you've found the problem. Also check if the Disk ID (signature) is all zeros—that's a dead giveaway.

Step 3: Clean the disk

This wipes everything. Be absolutely sure you have the right disk. Run:

select disk 5
clean
convert gpt

I use GPT because Windows Server clusters prefer it. If your environment is old-school MBR, use convert mbr instead, but don't.

Step 4: Create a single NTFS partition

create partition primary
format fs=ntfs quick label="Quorum"
assign

The quick format is fine here—no need to wait for a full format.

Step 5: Exit DiskPart and assign the quorum role

exit

Now in PowerShell or Failover Cluster Manager:

Set-ClusterQuorum -DiskWitness "Quorum"

Or in the GUI, right-click the cluster name, go to More Actions > Configure Cluster Quorum Settings, choose Add or change the quorum witness, pick Configure a disk witness, and select that disk.

What If It Still Fails?

If the error persists, check these three things:

  • Disk signature collision. Run Get-Disk | Select Number, UniqueId, PartitionStyle in PowerShell. If two disks share the same UniqueId, the cluster gets confused. Fix it by running Update-Disk -Number 5 to regenerate the signature. If that cmdlet isn't available (older OS), use diskpart -> uniqueid disk id=12345678 (pick a random hex value).
  • Multiple partitions. The quorum disk must have exactly one partition. If you see an EFI System Partition or recovery partition alongside the data partition, the cluster rejects it. Clean and re-create with only one partition.
  • Disk not visible on all nodes. Run Get-ClusterAvailableDisk on each node. If the disk doesn't show up, check SAN zoning, iSCSI initiator configuration, or MPIO settings. The cluster can't use a disk it can't see from all nodes.

One last thing: never try to use a dynamic disk or a storage space for quorum. The cluster expects a basic disk. If your SAN admin gave you a thin-provisioned LUN, that's fine—just make sure it's presented as a basic disk at the Windows layer.

Was this solution helpful?