BitLocker with Storage Spaces Direct (S2D): Why doesn’t the cluster absorb the recovery key like in standard CSVs?

Question

📄 Post Body:

I’m running a lab environment to validate BitLocker encryption on Cluster Shared Volumes (CSVs) and test how clusters behave under failover conditions — including when Active Directory is unavailable.

🔐 In my S2D environment, I had BitLocker enabled with both a recovery password protector and an AD-based protector (using the cluster’s computer object). However, during testing, when I shut down both domain controllers, the CSV failed to come online. This made it clear that the cluster was relying on Active Directory access to unlock the volume — and that’s a concern.

So I set out to make use of the cluster database key protector mechanism (as described in Microsoft’s own documentation) to ensure disks can be unlocked even without DCs online.

Scenario 1: Standard Hyper-V + iSCSI + CSV

In a classic failover cluster with iSCSI-attached storage and Hyper-V:

OS: Windows Server 2022 Datacenter

CSV disk: NTFS/ReFS, MBR

Cluster with two domain-joined nodes

I followed this guide: 🔗 https://learn.microsoft.com/en-us/windows-server/failover-clustering/bitlocker-on-csv-in-ws-2022#encrypting-using-external-recovery-key-file

Steps:

Add disk in Cluster Manager

Move it to maintenance mode

Run:

powershell
Copy
Enable-BitLocker -MountPoint "O:" -EncryptionMethod XtsAes256 -RecoveryPasswordProtector -UsedSpaceOnly
manage-bde -protectors -add "O:" -adaccountorgroup "domain\CLUSTERNAME$"

Extract protector details:

powershell
Copy
(Get-BitLockerVolume -MountPoint "O:\").KeyProtector

Register key with the cluster:

powershell
Copy
Get-ClusterSharedVolume "Cluster Disk 1" | Set-ClusterParameter -Name BitLockerProtectorInfo -Value "{GUID}:{RecoveryPassword}" -Create

1. To confirm whether the BitLocker key was actually stored in the cluster database, I ran:

      powershell
      Copy
      Get-ClusterKeyProtector
   

   This cmdlet returns any BitLocker keys stored in the cluster’s internal configuration — typically when .BEK
2. Take the resource offline, then bring it back online:

      powershell
      Copy
      Stop-ClusterResource "Cluster Disk 1"
   

Start-ClusterResource "Cluster Disk 1" Disk unlocks correctly during failover or reboot

Works even with both domain controllers offline

Get-BitLockerVolume shows FullyDecrypted

Cluster uses the stored key from BitLockerProtectorInfo reliably

---

Scenario 2: Storage Spaces Direct (S2D) (Not working)

Same OS (Windows Server 2022 Datacenter), but with S2D enabled. BitLocker encryption works fine:

powershell
Copy
Enable-BitLocker -MountPoint "X:" -EncryptionMethod XtsAes256 -RecoveryPasswordProtector

I then try the same method:

powershell
Copy
Set-ClusterParameter -Name BitLockerProtectorInfo -Value "{GUID}:{RecoveryPassword}" -Create

To confirm whether the BitLocker key was actually stored in the cluster database, I ran:

powershell
Copy
Get-ClusterKeyProtector

This cmdlet returns any BitLocker keys stored in the cluster’s internal configuration — typically when .BEK

But:

• The command succeeds without error
• The disk does not unlock when the node is rebooted or fails over
• Shutting down domain controllers causes the CSV to fail to mount
• Running Get-ClusterKeyProtector returns nothing — the key is not being absorbed into the cluster database

Result:

On my Hyper-V + iSCSI setup (where I used Set-ClusterParameter), this command returns nothing, which is expected — that method works independently of Get-ClusterKeyProtector.

On my S2D environment, after setting BitLockerProtectorInfo, Get-ClusterKeyProtector still returns nothing, suggesting:

The key is not stored in the S2D-aware cluster database, and S2D does not honor the BitLockerProtectorInfo mechanism

Question

Is BitLockerProtectorInfo not supported or ignored in Storage Spaces Direct (S2D)?

Do S2D deployments require using .BEK keys and Add-ClusterKeyProtector instead?

Is there a difference in how BitLocker unlock is handled between S2D and traditional failover clusters that is not documented?

This official guide does not mention any such distinction: 🔗 https://learn.microsoft.com/en-us/windows-server/failover-clustering/bitlocker-on-csv-in-ws-2022#encrypting-using-external-recovery-key-file

I'm looking for clarification or updated guidance specific to S2D-based CSV BitLocker unlock behavior, especially around domain independence and key storage.

Thanks in advance for any help or confirmation.

Answer 1

Hi Matt,

Thank you for laying out your concerns so clearly.

Let me walk through each point to help clarify things:

1. Is BitLockerProtectorInfo supported or used in S2D?

In Storage Spaces Direct (S2D) deployments, the traditional BitLockerProtectorInfo which is commonly used in standalone BitLocker setups or non-S2D failover clusters and may not function as expected with Cluster Shared Volumes (CSVs).

While this isn’t explicitly documented by Microsoft, the difference is due to S2D’s distributed storage architecture, where volumes are spread across multiple nodes. This model changes how unlock keys are managed and applied across the cluster.

2. Do S2D deployments require .BEK keys and Add-ClusterKeyProtector? Yes, for S2D-based CSVs, Microsoft recommends the following:

• Use .BEK files stored on an unencrypted volume or USB
• Use Add-ClusterKeyProtector to register the key protector cluster-wide

This setup ensures automatic unlocking across all nodes, even in domain-independent environments (e.g., workgroup or edge clusters).

3. Is BitLocker unlock handled differently in S2D vs. traditional clusters?

Absolutely. BitLocker unlock in S2D is handled differently due to its shared-nothing, distributed nature. In traditional clusters, standard protectors like TPM-only or AD-based are often sufficient.

However, in S2D:

The cluster service must manage volume unlock across nodes

TPM-only or AD-based protectors can fail during node reboots or when the cluster isn’t fully online

Microsoft’s best practice is to use .BEK + Add-ClusterKeyProtector to ensure reliability

In short, S2D clusters may bypass or ignore traditional BitLocker protectors for CSVs. While this behavior is observed in practice, it’s not thoroughly covered in most BitLocker or clustering documentation.

Hope this clears things up!