Introduction to BitLocker with TPM on Windows Server 2022

BitLocker Drive Encryption is a full-volume encryption feature built into Windows Server 2022 that protects data at rest by encrypting entire volumes using AES encryption. When combined with a Trusted Platform Module (TPM) chip, BitLocker provides hardware-backed key protection that ensures the encryption keys are only released during the boot process if the system configuration has not been tampered with. This makes BitLocker with TPM the strongest and most user-transparent form of server disk encryption available in Windows Server.

This article covers TPM requirements, checking TPM status, enabling BitLocker programmatically, adding PIN protectors, backing up recovery keys to Active Directory, checking BitLocker volume status, configuring Group Policy for BitLocker, and handling virtualized environments including Hyper-V with vTPM.

TPM Requirements for BitLocker on Windows Server 2022

BitLocker with TPM requires a physical TPM chip present on the server motherboard or a virtual TPM (vTPM) when running as a Hyper-V Generation 2 virtual machine. The requirements are:

  • TPM version: TPM 1.2 is the minimum requirement; TPM 2.0 is strongly preferred and is the standard on modern hardware. TPM 2.0 supports SHA-256 hashing, elliptic curve cryptography, and improved key hierarchies.
  • BIOS/UEFI: The firmware must support TPM and have it enabled. On modern servers this is typically handled in the UEFI settings under Security or Trusted Computing.
  • Secure Boot: While not mandatory for BitLocker with TPM, Secure Boot combined with BitLocker provides the strongest protection chain. When Secure Boot is active, the TPM seals keys against both the firmware state and the boot chain, detecting any unauthorized bootloader or kernel modifications.

On physical servers, confirm TPM is enabled in the UEFI firmware settings before attempting to configure BitLocker. If TPM is not detected, BitLocker can still be used with a startup key stored on a USB drive, but this removes the automatic boot capability.

Checking TPM Status with PowerShell and tpm.msc

Before enabling BitLocker, verify that TPM is present, enabled, and owned by Windows. Use the Get-Tpm PowerShell cmdlet for a full status report:

Get-Tpm

Expected output on a correctly configured server:

TpmPresent     : True
TpmReady       : True
TpmEnabled     : True
TpmActivated   : True
TpmOwned       : True
ManagedAuthLevel : Full
OwnerAuth      : 
OwnerClearDisabled : False
AutoProvisioning   : Enabled
LockedOut      : False
LockoutHealTime    : 10 minutes
LockoutCount   : 0
LockoutMax     : 31
SelfTest       : {191}

The key fields to verify are TpmPresent: True, TpmReady: True, and TpmEnabled: True. If TpmReady is False, the TPM may need to be initialized. Run:

Initialize-Tpm -AllowClear -AllowPhysicalPresence

On a desktop-experience server, you can also use the TPM Management Console by running tpm.msc. This GUI shows the TPM manufacturer, version, firmware version, and allows you to change the TPM owner password. For headless Server Core environments, all TPM management must be done through PowerShell.

To check the TPM specification version specifically (to confirm TPM 2.0):

Get-WmiObject -Namespace "rootcimv2securitymicrosofttpm" -Class Win32_Tpm | Select-Object SpecVersion

Enabling BitLocker with TPM Only Protector

The simplest and most common BitLocker configuration for servers is TPM-only protection. In this mode, the TPM automatically releases the encryption key at boot time without requiring any PIN or startup key, as long as the system boot chain is unchanged. This is ideal for servers that must reboot automatically (for patching or failover) without requiring operator intervention.

To enable BitLocker on the C: drive using only the TPM protector:

Enable-BitLocker -MountPoint "C:" -TpmProtector

After running this command, BitLocker begins encrypting the volume in the background. The encryption process is transparent to running services. To monitor encryption progress:

Get-BitLockerVolume -MountPoint "C:" | Select-Object MountPoint, EncryptionPercentage, VolumeStatus

The VolumeStatus field will show EncryptionInProgress until complete, then change to FullyEncrypted. On a large system volume, full encryption can take several hours, though the system remains fully operational throughout.

Before the encryption completes and BitLocker is fully active, you must add a recovery key protector. BitLocker will not fully arm without a recovery option configured. This is covered in the next sections.

Adding TPM+PIN Protector

For higher security environments where servers are in physically insecure locations or where regulatory compliance requires multi-factor boot authentication, you can add a PIN to the TPM protector. With TPM+PIN, the server requires operator input of a PIN at every boot before the TPM releases the volume key. This prevents the server from booting unattended if it is physically stolen.

To add a PIN protector to an already-BitLocker-enabled volume:

$SecurePin = ConvertTo-SecureString "YourPIN1234" -AsPlainText -Force
Add-BitLockerKeyProtector -MountPoint "C:" -TpmAndPinProtector -Pin $SecurePin

To enable BitLocker fresh with a TPM+PIN combination in a single command:

$SecurePin = ConvertTo-SecureString "YourPIN1234" -AsPlainText -Force
Enable-BitLocker -MountPoint "C:" -TpmAndPinProtector -Pin $SecurePin

Note that enabling TPM+PIN means the server will halt at the BitLocker PIN prompt on every boot and reboot. This is appropriate for some compliance scenarios (PCI-DSS, certain DoD STIGs) but is generally impractical for servers that need to restart without operator involvement. For unattended reboots, TPM-only is the appropriate choice.

Group Policy can be used to enforce PIN complexity requirements. The relevant policy is under:

Computer Configuration > Administrative Templates > Windows Components > BitLocker Drive Encryption > Operating System Drives > Require additional authentication at startup

Generating and Backing Up Recovery Keys to Active Directory

A BitLocker recovery key is a 48-digit numerical password that can unlock an encrypted volume if the normal boot path fails — for example, after a hardware change that causes the TPM to reject the boot measurement, after a BIOS update, or if the PIN is forgotten. Backing up recovery keys to Active Directory ensures they can always be retrieved by an authorized administrator.

First, add a recovery password protector to generate the recovery key:

Add-BitLockerKeyProtector -MountPoint "C:" -RecoveryPasswordProtector

This generates a recovery key and adds it as a protector. To view the key immediately:

Get-BitLockerVolume -MountPoint "C:" | Select-Object -ExpandProperty KeyProtector

The output lists all protectors. Find the one with KeyProtectorType: RecoveryPassword and note its KeyProtectorId. Then back it up to Active Directory:

# Get the recovery key protector ID
$vol = Get-BitLockerVolume -MountPoint "C:"
$keyId = ($vol.KeyProtector | Where-Object { $_.KeyProtectorType -eq "RecoveryPassword" }).KeyProtectorId

# Backup to Active Directory
Backup-BitLockerKeyProtector -MountPoint "C:" -KeyProtectorId $keyId

The recovery key is then stored in the computer’s Active Directory object and can be retrieved by a Domain Admin using the BitLocker Recovery Password Viewer RSAT tool, or via the Active Directory Users and Computers snap-in under the computer object’s BitLocker Recovery tab.

Group Policy can enforce that BitLocker does not enable until a recovery key is backed up to AD. Navigate to:

Computer Configuration > Administrative Templates > Windows Components > BitLocker Drive Encryption > Operating System Drives > Do not enable BitLocker until recovery information is stored to AD DS

Checking BitLocker Volume Status with Get-BitLockerVolume

To view the complete BitLocker status for all volumes on a server:

Get-BitLockerVolume

To see detailed information for a specific volume including all key protectors:

Get-BitLockerVolume -MountPoint "C:" | Format-List

Key fields in the output:

  • VolumeStatus: FullyEncrypted, EncryptionInProgress, FullyDecrypted
  • EncryptionPercentage: 0–100
  • EncryptionMethod: XtsAes256 (default and recommended on Server 2022)
  • ProtectionStatus: On or Off — “On” means the TPM is actively protecting and the key is sealed
  • LockStatus: Unlocked or Locked
  • KeyProtector: Array of all configured protectors (Tpm, RecoveryPassword, TpmPin, etc.)

To suspend BitLocker temporarily (for firmware updates that would otherwise trigger TPM lockout):

Suspend-BitLocker -MountPoint "C:" -RebootCount 1

The -RebootCount 1 parameter automatically resumes protection after one reboot. This is the recommended procedure before any BIOS/UEFI update.

BitLocker on Virtual Machines with vTPM in Hyper-V

On Hyper-V Generation 2 virtual machines running Windows Server 2022, BitLocker can be configured using a virtual TPM (vTPM). The vTPM is emulated by the Hyper-V hypervisor and presents a TPM 2.0 interface to the guest OS, allowing BitLocker to function identically to a physical machine.

To enable vTPM on a Hyper-V VM (run on the Hyper-V host, not the guest):

$VMName = "WS2022-Server01"
Set-VMKeyProtector -VMName $VMName -NewLocalKeyProtector
Enable-VMTPM -VMName $VMName

After enabling vTPM, start the VM. Inside the guest OS, verify the TPM is detected:

Get-Tpm

You should see TpmPresent: True and TpmReady: True. Now proceed to enable BitLocker normally using the same Enable-BitLocker commands described earlier.

For VMs that do not have vTPM (Generation 1 VMs or VMs moved from non-Hyper-V hypervisors), BitLocker can be configured with a startup key stored in the VM’s configuration using the -StartupKeyProtector option:

Enable-BitLocker -MountPoint "C:" -StartupKeyProtector -StartupKeyPath "C:BitLockerKey"

The resulting startup key file must be present at boot time. In a VM context, this file is typically stored in the VM’s virtual disk alongside the OS volume. This provides encryption at rest on the physical host storage, though the protection model is weaker than TPM-backed encryption since the key is accessible without special hardware.

When configuring BitLocker in virtualized server environments, coordinate with your storage and backup teams. Ensure that backup agents can read encrypted volumes (most modern backup software handles this transparently at the block level when run from within the guest OS) and that snapshots do not expose unencrypted data at the hypervisor layer — which is a risk mitigated by vTPM-backed BitLocker.