- New Group Policy settings in Windows 11 23H2 - Mon, Nov 20 2023
- Windows Server 2025 will support SMB over QUIC in all editions - Fri, Nov 17 2023
- Switch between Windows Terminal and the legacy console - Thu, Nov 16 2023
In general, admins appreciate a mechanism to centrally trigger BitLocker encryption. However, this capability is only part of various endpoint management tools, such as Intune.
Automatic BitLocker activation
BitLocker does indeed have an automatic encryption feature, but it only kicks in under specific conditions. This includes having modern hardware with TPM (1.2 or 2.0) and UEFI Secure Boot, Platform Secure Boot, and DMA enabled.
However, encryption only starts when the user logs into his Microsoft account or Entra ID (Azure AD). If you're working with local or domain accounts, automatic encryption won't work.
Hence, in on-premises environments, BitLocker needs to be initiated differently. You can achieve this using the "manage-bde" utility, a PowerShell script with native BitLocker cmdlets, or WMI.
Protectors as a prerequisite
BitLocker supports a variety of protectors whose role is to safeguard or release the volume encryption key once the system's integrity or the user's legitimacy has been verified.
Therefore, encryption cannot commence until at least one protector has been configured. If you try it anyway, for example, via the WMI function encrypt(), you will encounter the error 0x8031002E (2150694958).
Both manage-bde and Enable-BitLocker offer the option of configuring protectors when activating encryption. With WMI, these are separate processes.
Separating the creation of protectors from activating encryption is needed if you want to generate protectors during the OS deployment phase and trigger encryption afterwards. However, the hurdles for this approach are quite high because BitLocker doesn't provide a way to force users to change a standard PIN assigned during deployment.
Regardless of the method chosen, it can only create protectors that do not conflict with group policies. For example, if you have excluded the TPM protector or certain combinations with TPM via the Require additional authentication at startup setting, then you will obviously not be able to create them at the command line afterwards either.
Certain protectors fail when you try to set them up, even without having excluded them via group policies, because they are not allowed via the default settings. This is especially true for protecting system drives with a password alone. Trying to set up this protector results in error code 0x8031006A (2150695018).
Configuring TPM and PIN, on the other hand, behaves in the opposite way. If you do not explicitly allow this protector via a group policy, the process fails with error code 0x80310060 (2150695008). However, this is not true for TPM alone.
Finally, it is important to remember that not all protectors are suitable for all drives. TPM and combinations with TPM are reserved for system drives, while Auto Unlock, for example, only works for data drives.
The command to activate encryption using manage-bde looks like this:
manage-bde -on <drive:>
If no protectors exist, this command will attempt to automatically set up a TPM protector. If this is not possible due to a group policy, the command will fail.
Alternatively, you can create protectors on the spot by giving the command the appropriate parameters:
- RecoveryPassword or -rp
- RecoveryKey or -rk
- StartupKey or -sk
- Certificate or -cert
- TPMAndPIN or -tp
- TPMAndStartupKey or -tsk
- TPMAndPINAndStartupKey or -tpsk
- Password or -pw
- ADAccountOrGroup or -sid
An example of a system drive could look like this:
manage-bde -on C: -RecoveryPassword -UsedSpaceOnly
Additional options, such as UsedSpaceOnly and SkipHardwareTest, are available to encrypt only the used disk space or skip the hardware test. You can also use the ComputerName or cn parameter to activate BitLocker remotely on other PCs.
If you prefer to use PowerShell to initiate BitLocker, the Enable-BitLocker cmdlet is responsible for this task. You can also configure protectors with it; the parameters are similar to those of Add-BitLockerKeyProtector. Here's an example:
$pin = Read-Host -AsSecureString -Prompt "Enter PIN" Enable-BitLocker -MountPoint c: -TpmAndPinProtector -Pin $pin
In this PowerShell example, you can also include the SkipHardwareTest and UsedSpaceOnly switches, as needed.
For remote management, the ComputerName parameter is not supported, so you will have to open a session on the target PC and execute the command there.
The WMI class Win32_EncryptableVolume provides the functions Encrypt() and EncryptAfterHardwareTest() for this purpose. The latter requires a reboot of the computer. Both assume that the required protectors exist; they cannot be created using these methods.
Here is an example call:
$bl = Get-WmiObject -Namespace "Root\cimv2\security\MicrosoftVolumeEncryption" ` -ClassName Win32_EncryptableVolume -Filter 'DriveLetter="c:"' ` -ComputerName win11-vm1-l1 $bl.Encrypt()
As indicated by the ComputerName parameter, this command activates encryption on a remote PC. Both functions, Encrypt() and EncryptAfterHardwareTest(), are available through Get-WmiObject but not with Get-CimInstance.
Group Policies can be used to configure BitLocker settings, but they do not facilitate the creation of required protectors or the initiation of encryption. Manage-bde and Enable-BitLocker can perform both tasks in a single pass, whereas the WMI class Win32_EncryptableVolume provides separate functions for these purposes.
Subscribe to 4sysops newsletter!
It's important to note that BitLocker management cmdlets cannot be applied to remote PCs. As an alternative, you can use the WMI functions, but manage-bde also supports the ComputerName parameter for remote management.