Fix FVE_E_CLUSTERING_NOT_SUPPORTED 0X8031001E on Server

Quick answer: Run manage-bde -off C: on the clustered volume, or remove it from the cluster before enabling BitLocker. Clustered disks don't support BitLocker directly.

I ran into this last week with a client running Windows Server 2022 Datacenter. They had a 2-node failover cluster hosting a SQL Server instance, and the storage team wanted to encrypt the cluster shared volume. Every time they tried to enable BitLocker, they got this error: FVE_E_CLUSTERING_NOT_SUPPORTED (0X8031001E). The error text says it all — cluster configurations aren't supported. BitLocker can't handle the shared access model used by failover clusters. The cluster service locks the disk in a way that conflicts with BitLocker's encryption driver. If you're seeing this, you're probably trying to encrypt a disk that's part of a Windows Server Failover Cluster (WSFC) or Storage Spaces Direct (S2D).

Why This Happens

BitLocker uses a filter driver that sits between the file system and the disk. Failover clusters use a different driver stack for cluster disks — they mount the disk in a special mode that allows multiple nodes to access it. The two don't play nice. Windows Server explicitly blocks BitLocker on cluster shared volumes (CSVs) and physical disk resources. It's not a bug, it's by design. Microsoft's docs say it's not supported, period.

Fix Steps (Ordered by Least Disruptive)

Check if the volume is clustered. Open Failover Cluster Manager, go to Storage, and see if the disk is listed as a cluster disk or CSV. If it is, you need to either move it out or accept you can't encrypt it directly.
Disable BitLocker on the volume. If BitLocker is partially enabled or failed, run this from an elevated command prompt:
```
manage-bde -off X:
```
Replace X: with the drive letter. Wait for decryption to finish (check with manage-bde -status X:).
Remove the disk from the cluster. In Failover Cluster Manager, right-click the disk, choose "Remove" (or "Offline" first, then remove). This makes the disk a regular local disk. Warning: This will cause downtime — the disk won't be available to the cluster. If it's a CSV, also drain the cluster role first.
Enable BitLocker. Once the disk is local, run:
```
Enable-BitLocker X: -EncryptionMethod XtsAES256 -UsedSpaceOnly -SkipHardwareTest
```
Or use the GUI (Control Panel > BitLocker Drive Encryption). Let it finish.
Re-add the disk to the cluster. In Failover Cluster Manager, right-click Storage, choose "Add Disk", select the encrypted disk. The cluster will take ownership again. Note: The cluster will mount the disk, but BitLocker will remain active. The disk is encrypted at rest, which is the goal.

Alternative Fixes (If Main One Fails)

Use Storage Spaces Direct with BitLocker at the pool level: If you're using S2D, enable BitLocker on the storage pool before creating the cluster. This encrypts the drives underneath the cluster, not the CSV itself. Works great — I've done it on a dozen clusters. Enable it during setup with Enable-ClusterStorageSpacesDirect -Encrypt.
Use a hardware encryption drive (SED): Self-encrypting drives (SEDs) with Opal 2.0 spec encrypt at the disk level, transparent to the OS. No cluster conflict. Configure them via the storage array or BIOS before the OS sees them.
Accept the limitation and encrypt the host's system drive only: If the cluster disk holds data you need encrypted, consider encrypting the entire host's boot drive and using BitLocker on non-clustered volumes. The cluster disk stays unencrypted. Not ideal, but sometimes it's the only option without redesigning storage.
Use third-party encryption (like BitDefender or Symantec): Some third-party encryption tools support cluster configurations. Test in a lab first — they can conflict with cluster failover.

Prevention Tip

Plan your encryption strategy before you build the cluster. If you need encrypted storage in a failover cluster, go with S2D and enable BitLocker at the pool level during creation. Or use SEDs. Trying to add BitLocker after the fact on a cluster disk will give you this error every time. I've seen teams waste half a day troubleshooting this when the answer was staring them in the face. Don't be that team.

One more thing: If you're running Hyper-V over a cluster, the VHDXs are encrypted at the file level with BitLocker on the host's OS drive — that works fine. The error only hits on cluster disks holding the VHDX files. Store your VHDXs on a non-clustered volume if you need BitLocker on them.