How to Configure BitLocker Encrypted Clustered Disks in Windows Server 2012

First published on MSDN on Jul 20, 2012

2012 introduces the ability to encrypt Shared Volumes (CSV) using BitLocker®.  You can learn more about BitLocker



Data on a lost or stolen storage is vulnerable to unauthorized access, either by running a software-attack tool against it or by transferring the storage to a different server. BitLocker helps mitigate unauthorized data access by enhancing file and system protections. BitLocker also helps render data inaccessible when BitLocker-protected storage is decommissioned or recycled. BitLocker on a Clustered Disk, either a traditional Physical Disk Resource (PDR) or Shared Volume  therefore allows for an additional layer of protection for administrators wishing to protect sensitive, highly available data. By adding additional protectors to the clustered volume, administrators can also add an additional barrier of security to resources within an organization by allowing only certain user accounts access to unlock the BitLocker volume.

This blog outlines the sequence of steps to configure BitLocker on a Clustered disk using Windows PowerShell®


  • A 2012 (DC) is reachable from all nodes in the .
  • Enable the policy –
    Choose how bitlocker-protected fixed drivers can be recovered.
  • The BitLocker Drive feature is installed on all nodes in the cluster. To install, open a Windows PowerShell console and run:



Note: The cluster node will need to be restarted after installing the BitLocker Drive Encryption feature.

  • Ensure that the disk to be encrypted is formatted with NTFS. For a traditional PDR you need to assign a drive letter to the disk. For CSV you can use the mount point for the volume. Partition, initialize and format the disk if required. Open a Windows PowerShell console and run:


-Number -PartitionStyle

Steps to configure using Windows PowerShell

BitLocker Drive Encryption can be turned on for both traditional Failover cluster disks as well as Cluster Shared Volumes (CSV). BitLocker encrypts at the volume level, so if a clustered disk consists of more than one volume and you may want to protect the entire disk, by turning BitLocker protection on each volume of the disk.

Volumes can be encrypted before adding them to a cluster. Additionally, data volumes already in use by clustered workloads can be encrypted.

To configure, open a Windows PowerShell console and run the following steps:

1.      If the Clustered disk is currently added to a cluster and Online put it into maintenance mode.

Traditional PDR:


“Cluster Disk 1” |


Cluster Shared Volumes:


“Cluster Disk 1” |


2.      Configure BitLocker® on the volume using your choice of protector.

To enable using a password protector:

$SecureString = ConvertTo-SecureString -AsPlainText -Force

Enable-BitLocker -PasswordProtector –Password $SecureString

Recovery Password Protector

Creating a recovery password and backing up the password in Active Directory (AD) provides a mechanism to restore access to a BitLocker protected drive in the event that the drive cannot be unlocked normally. A domain administrator can obtain the recovery password from AD and use it to unlock and access the drive. Some of the reasons a BitLocker recovery might be necessary include:

  • The CNO used to establish a SID protector in step 4 has been accidently deleted from AD.
  • An attacker has modified your server. This is applicable for a computer with a Trusted Platform Module () because the checks the integrity of boot components during startup

To enable using a recovery password protector and backup the protector to Active Directory:

Enable-BitLocker -RecoveryPasswordProtector

$protectorId = (Get-BitLockerVolume ).Keyprotector | Where-Object {$_.KeyProtectorType -eq “RecoveryPassword”}

Backup-BitLockerKeyProtector -KeyProtectorId $protectorId.KeyProtectorId

To disable:


Warning: It is important for you to capture and secure the password protector for future use.

Note: During encryption, a CSV Volume will be in Redirected mode until BitLocker builds its metadata and watermark on all data present on the encrypted volume. The duration of redirected mode will be proportional to the size of the volume, the real data size and BitLocker encryption mode picked (DataOnly or Full). The BitLocker encryption rate is typically in the order of minutes per Giga Byte. The cluster service will switch to Direct I/O mode within 3 minutes after encryption has completed.

3.      Determine the Cluster Name Object for your cluster:

$cno = (Get-Cluster).name + “$”

4.      Add an Active Directory Security Identifier (SID) to the CSV disk using the Cluster Name Object (CNO)

The Active Directory protector is a domain security identifier (SID) based protector for protecting clustered volumes held within the Active Directory infrastructure. It can be bound to a user account, machine account or group.  When an unlock request is made for a protected volume, the BitLocker service interrupts the request and uses the BitLocker protect/unprotect APIs to unlock or deny the request.  For the cluster service to self-manage BitLocker enabled disk volumes, an administrator must add the Cluster Name Object (CNO), which is the Active Directory identity associated with the Cluster name, as a BitLocker protector to the target disk volumes.

Add-BitLockerKeyProtector -ADAccountOrGroupProtector –ADAccountOrGroup $cno

Warning: You must add a SID based protector using the CNO for an encrypted Clustered Disk. This is necessary for the cluster service to automatically unlock when surfacing the BitLocker protected volumes on one or more nodes of the cluster.

5.      If the CSV disk was put it into maintenance mode in step 1, resume operation of the disk.

Traditional PDR:


“Cluster Disk 1” |


Cluster Shared Volumes:


“Cluster Disk 1” |


6.      If the disk had not been added to the cluster and optionally added to CSV you may do so now.


-DriveLetter | Get-Disk |





Subhasish Bhattacharya

Senior Program Manager

Clustering and High Availability



This article was originally published by Microsoft’s Failover Clustering Blog. You can find the original article here.