Fix ERROR_CLUSTER_QUORUMLOG_NOT_FOUND (0X00001703)

When this error hits

You're managing a Windows Failover Cluster — Server 2016, 2019, or 2022. One node goes offline, or you reboot a cluster node after a storage hiccup. When the node tries to join the cluster, it throws ERROR_CLUSTER_QUORUMLOG_NOT_FOUND (0X00001703) in the System event log. The cluster service fails to start on that node, and you see "The quorum resource does not contain the quorum log" in Event ID 1581 or 1069.

The culprit here is almost always a corrupted or missing quolog.log file on the quorum witness disk, or a stale node that can't sync because another node already changed the quorum configuration.

Root cause in plain English

The quorum disk acts like a tiebreaker for cluster decisions. It keeps a small log file (quolog.log) that tracks cluster state changes. If that file gets corrupted during a power loss, or if you removed and re-added the quorum disk without cleaning the old log, the cluster can't validate the node's last known state. The node says "I need to see this log," the disk says "I don't have it," and you get stuck.

One specific trigger: You changed the quorum witness from a file share witness to a disk witness, and the node that's offline still references the old witness path. The node's local copy of the cluster database is out of sync with the active cluster.

The fix — three approaches

Approach 1: Force the node to rebuild from the cluster

This works if the node can communicate with the cluster network but the disk is just stale.

1. On a working node, open PowerShell as admin.
2. Run Get-ClusterNode to confirm the problem node shows as Down.
3. Run Get-ClusterResource | Where-Object {$_.ResourceType -eq "Physical Disk"} to find your quorum disk.
4. Make sure the quorum disk is online and accessible from the working node. Check Disk Management.
5. On the problem node, force the service to sync by clearing its local cluster database:
   

   Stop-Service ClusSvc
   Remove-Item "C:\Windows\Cluster\CLUSDB\*" -Force
   Start-Service ClusSvc

6. The node will pull the cluster database from quorum. It should join the cluster within 30 seconds.

Approach 2: Rebuild the quorum log manually

If the above fails, the log itself might be hosed. Don't bother trying to open or edit quolog.log — it's binary garbage. Just replace it.

1. On a working node, identify the quorum disk drive letter. Usually it's the small LUN (1 GB or less) dedicated to quorum.
2. Open File Explorer to that drive. You'll see a hidden folder \Cluster. Show hidden files if needed.
3. Inside \Cluster, there's quolog.log. Copy it to a safe backup first.
4. Delete the original quolog.log from that folder.
5. Open PowerShell as admin on the working node and run:
   

   Stop-Service ClusSvc
   Start-Service ClusSvc

6. The cluster service will create a fresh quolog.log from the current database. Check the file reappeared.
7. Now restart the cluster service on the problem node.

Approach 3: Nuke the quorum configuration and rebuild

This is your last resort — affects the whole cluster briefly. Only use if you can afford 5 minutes of downtime.

1. On the active node, open Failover Cluster Manager.
2. Right-click the cluster name, go to More Actions > Reset Cluster Quorum Settings.
3. Select Use default quorum configuration, apply it.
4. Now reconfigure your quorum witness to the disk witness again.
5. Run Test-Cluster to validate everything.
6. Restart all nodes one by one — the problem node last.

What to check if it still fails

If none of that worked, you've got deeper issues.

• Check disk health: Run chkdsk /f on the quorum LUN from a working node. Bad sectors can corrupt the log even after a rebuild.
• Cluster network isolation: The problem node might not be on the correct subnet or VLAN. Ping the quorum disk's IP (if it's shared storage) from the problem node.
• Stale node database: Sometimes the node's registry has a different quorum resource GUID. Compare HKLM\Cluster\Nodes\NodeID\QuorumPath on a working node vs. the problem node. Back up the registry first, then match the GUID.
• Antivirus interference: I've seen AV lock the quolog.log file. Exclude C:\Windows\Cluster\ and the quorum disk path from real-time scanning.

If you're still stuck after 30 minutes, force evict the node from the cluster (yes, it's risky) and re-add it. Use Remove-ClusterNode from a working node, then rejoin the problem node fresh.