TL;DR: Manage BitLocker with three PDQ scanners, six package scripts, and three reports. Collect device information, prepare the TPM and BitLocker policy, enable encryption, and review the results. Get the scripts, then build the reports using the settings below.

Admins have asked how to check BitLocker protection and access recovery information in PDQ. I put together a set of scanners, package scripts, and report examples so you can start with the components you need instead of writing everything from scratch.

Scanners: Collect TPM and BitLocker information

The three scanners collect device information without enabling encryption or changing settings.

Scanner name	Script	What it does
TPM Capabilities	`Get-TpmCapabilities.ps1`	Reports TPM readiness, manufacturer and version information, firmware type, Secure Boot status, and lockout details. Includes diagnostic information when values cannot be read.
Bitlocker Status	`Get-BitLockerStatus.ps1`	Reports each volume’s encryption progress, protection status, lock status, and protector types. Includes an assessment, errors, and warnings.
Bitlocker Protectors	`Get-BitLockerProtectors.ps1`	Lists each volume’s key protectors, reads recovery passwords locally, and checks local event logs for recovery-backup history.

Run the scanners using Windows PowerShell 5.1 as SYSTEM or a local administrator.

Before running the protectors scanner: If the volume is using a RecoveryPassword protector and the password is stored locally, then this script will capture the recovery password into the scan results. Therefore, restrict access to both the scanner data and reports that use it. Reading a recovery password requires an elevated scan and an unlocked volume.

The scripts are available from the Powershell-Scanners github repository under PowerShell Scanners/Bitlocker Mgmt/scanners. In PDQ, create one custom PowerShell scanner per script, paste the script, set it to run as System, and choose a scan schedule. Use the scanner names above to match the report sources below.

Start with a small test group. Review TpmQueryStatus, BitLockerQueryStatus, and Assessment before deciding which devices need changes.

Packages: Prepare, encrypt, or remove BitLocker settings

The six package scripts cover TPM preparation, policy configuration, encryption, and removal. For enablement, prepare the TPM where needed, apply policy, and then enable the protectors and encryption. Note, if the TPM is not available or not configured (for example, no vTPM on a Virtual Machine), then TPM and Bitlocker configuration will not work as the TPM is a prerequisite.

Package script	What it does
`Set-TpmReady.ps1`	Enables automatic provisioning and initializes a TPM that is present and enabled but not ready. It cannot enable a TPM that is disabled in firmware or add a missing TPM.
`Set-BitlockerPolicy.ps1`	Applies the settings in its $Policy table and backs up the original values. It refuses to change existing policy values outside its own backup. Policy changes do not re-encrypt existing volumes.
`Enable-BitLockerProtectors.ps1`	Adds the requested protectors and starts encryption when the volume is fully decrypted. The default protector combination is TPM plus a recovery password.
`Remove-BitlockerPolicy.ps1`	Restores the policy values saved by the policy-setting script. It does not change encryption or protectors.
`Remove-BitLockerProtectors.ps1`	Removes specified protector types or IDs. It does not decrypt the volume.
`Disable-BitLocker.ps1`	Removes all key protectors and starts decryption. Use it only when you intend to turn off BitLocker for the target volume.

The package workflow requires Windows PowerShell 5.1, SYSTEM or local administrator permissions, and the BitLocker PowerShell module. TPM-related operations also use Get-Tpm. The default encryption configuration requires a present, ready TPM.

Get the scripts from the Powershell-Scanners repository under Packages/Bitlocker Mgmt/packages. Create custom Windows packages with PowerShell steps running as System, using the repository’s parameter instructions.

Before deployment, review the policy table and package parameters. Every package supports -DryRun $true; enable dry run explicitly when testing policy changes or removals. Keep these settings in mind:

TPM clearing: Leave -ClearIfNeeded at its default of $false for routine setup. Clearing destroys keys stored in the TPM.
Recovery backup: -BackupToAD and -BackupToEntra both default to $false. Configure the appropriate option for your environment and verify recovery access.
Recovery-password output: -ReturnRecoveryPassword defaults to $true, which puts the password in deployment logs. Set it to $false to suppress that output. The protectors scanner will still collect recovery passwords when it runs.

Apply policy before encryption so the intended settings are in place. After running the packages, collect fresh scanner data rather than relying only on successful package execution.

Reports: Review TPM and BitLocker results

Once the scanners have returned data, create three Standard reports in PDQ. Open Reports, create a report, and add the device and scanner columns below. The examples target All devices, with Group by unchecked.

Only devices with scanner data appear. Check scan coverage before interpreting a missing device as protected, unprotected, or free of errors.

TPM summary

Use the TPM summary report to review platform information, TPM readiness, and lockout status.

Source	Columns, in order
Device	`Name`, `Manufacturer`, `Model`, `Architecture`
TPM Capabilities	`IsVirtualMachine`, `FirmwareType`, `TpmManufacturerVersion`, `TpmManufacturer`, `TpmEnabled`, `TpmReady`, `SecureBootEnabled`, `TpmLockedOut`, `TpmLockoutCount`

Result filters: None.

When TPM information is missing, review the scanner’s TpmQueryStatus, TpmError, and TpmNextStep fields to understand why.

BitLocker status

Use the BitLocker status report to review each volume’s protection state, protectors, and diagnostic information.

Source	Columns, in order
Device	`Name`
Bitlocker Status	`TpmReady`, `Assessment`, `MountPoint`, `ProtectionStatus`, `LockStatus`, `KeyProtectors`, `BitLockerError`, `BitLockerWarnings`

Result filters: To reproduce the supplied example, set OS to Any and add Bitlocker Status: TpmReady → is → true.

That filter limits the report to TPM-ready devices. Leave it off when you need to investigate devices with false or missing readiness values.

Optional: Add ConversionStatus and PercentEncrypted to track encryption progress alongside protection status.

After deployment, check for the intended protector configuration and ProtectionStatus of On (1). Review encryption progress separately so an operation still in progress is not mistaken for a completed deployment.

BitLocker recovery passwords

Use the recovery-password report to associate locally collected passwords with devices, volumes, and protector IDs.

Source	Columns, in order
Device	`Name`
Bitlocker Protectors	`MountPoint`, `KeyProtectorType`, `KeyProtectorId`, `RecoveryPassword`, `RecoverySource`, `RecoveryBackup`

Result filters: Set OS to Windows and filter KeyProtectorType to values containing RecoveryPassword. This includes values such as RecoveryPassword (3) and excludes TPM-only rows.

RecoverySource indicates whether the password was read locally. RecoveryBackup summarizes backup activity recorded in the device’s event log. It does not query Microsoft Entra ID or Active Directory, perform a backup, or verify that a password is currently retrievable.

No backup event found does not prove that a backup is missing, because older events may no longer be available. Verify recovery access in your approved backup location.

Treat the report as sensitive: restrict access, do not email password-bearing exports, and delete downloaded CSVs when finished.

The workflow is straightforward: scan, prepare the TPM and policy, encrypt, and rescan. Use the reports to confirm the resulting device state and identify anything that needs attention.