manage-bde isn't broken, BitLocker just isn't installed

I had a fleet-status dashboard for some Windows boxes that pulled disk encryption state via manage-bde -status. Several rows were reporting hard errors. Turns out they weren't errors — the dashboard was lying about the failure mode.

What was happening

'manage-bde' is not recognized as an internal or external command,
operable program or batch file.

My dashboard collector was treating any non-zero return code or stderr output as "encryption check failed" and showing a red box. Several Windows Server VMs were red. The hosts were healthy, accessible over WinRM, and otherwise fine. They just didn't have manage-bde.

What I found

BitLocker is an optional Windows feature. Workstations (Windows 10/11 Pro and up) ship with it preinstalled. Server SKUs — 2016 through 2025 — and most generic VMs don't include it unless you explicitly add the feature:

Install-WindowsFeature -Name BitLocker -IncludeAllSubFeature -Restart

If BitLocker isn't installed, manage-bde.exe literally isn't on PATH. The shell can't find the binary, so it returns the standard "not recognized" message and exits non-zero.

You can confirm whether the feature is even present without calling manage-bde at all:

Get-CimInstance -Namespace root\cimv2\Security\MicrosoftVolumeEncryption `
                -ClassName Win32_EncryptableVolume -ErrorAction SilentlyContinue

If the CIM namespace returns nothing, the encryption feature isn't installed. That's a different state from "installed but disabled" and a very different state from "installed, enabled, and failing."

The fix

Three states instead of two in the dashboard collector. Pseudocode:

def encryption_state(host):
    if not feature_present(host):
        return "feature_not_installed"
    status = run_manage_bde(host)
    if status.is_encrypted:
        return "encrypted"
    return "unencrypted"

And the dashboard renders feature_not_installed as a neutral gray instead of red. It's accurate, and it means the red boxes I have left actually represent things I should look at.

What I'd do differently

The general lesson: when you're polling a feature, your collector needs to be able to tell the difference between "feature absent," "feature present but disabled," and "feature broken." Collapsing all three into "error" gives you a dashboard full of false positives, which trains you to ignore the dashboard, which is the worst outcome a monitoring system can have. WMI/CIM namespace presence is usually a clean way to detect feature install state on Windows without needing to call the feature's own tooling.