Manage BitLocker Easily

Get an Agent on Every Machine First

The console can only manage what it can see. Every PC first needs the Endpoint Central agent installed and reporting in — without an agent, a machine is invisible to the policy, to the key vault and to every report in this guide.

Compare the console's machine list against what the office actually owns — purchase records, the Active Directory computer list, a network scan. Any PC that is missing is not "probably encrypted"; it is unknown, and unknown is the risk. Fleet encryption projects usually fail at this visibility step, not at the encryption step — close the gap first.

Write One Policy Before Touching Any PC

Create the BitLocker policy centrally instead of configuring PCs one by one. A policy is one definition of "encrypted properly", and the video's walkthrough sets the decisions that matter:

Protector: TPM only unlocks the drive automatically at boot — a stolen laptop still reaches the Windows login screen. TPM + PIN asks for a PIN before Windows even starts, which is the setting that genuinely stops a thief; for laptops that travel, it is worth the small daily friction. Machines without a TPM can use a passphrase protector — a deliberate choice, never an accident.

Algorithm and scope: XTS-AES 128 or 256 (256 is what most auditors like to see written down; neither is being brute-forced in practice), and used-space-only encryption for brand-new machines versus full disk for any machine already in service, because "empty" space still holds deleted files.

Set Up Key Escrow — and Verify It Before Enforcing Anything

Every BitLocker drive has a 48-digit recovery key, and on the day a PC shows the blue recovery screen, that key is the only thing between the user and a wiped drive. Escrow means the key is collected automatically and stored where the organisation controls it: on the Endpoint Central server, with the option to also back keys up into Active Directory or Azure AD.

Endpoint Central's rule is strict, and the strictness is the feature: encryption does not start until the recovery key has been safely stored on the server. A drive can never end up encrypted with its only key stranded on the machine itself.

Push the Policy to a Pilot Group First

Deploy the finished policy to a small pilot group before the whole office — a few machines you can walk over to. Watch them move through the console states, confirm each one's recovery key landed in the vault, and only then widen the rollout to groups of machines (ManageEngine documents pushes of up to 250 devices at a time). New machines can pick the policy up automatically as they join, so the fleet stays covered after the project ends.

Read the Status Board — Encrypted, Pending, Non-compliant

From here the job is reading, not travelling. The console's BitLocker Managed Computers view carries every managed machine in one of three states: Encrypted, Pending encryption or Non-compliant. That board — not a walk around the office — is how you answer "which of our PCs are still not encrypted?"

Work the Gap List in Risk Order

"Pending" and "Non-compliant" are symptoms, not diagnoses. The usual causes: the machine has not checked in (off, on leave, agent stopped reporting); a prerequisite failed — the console's pre-deployment checks flag classics like BIOS mode incompatibility and TPM ownership errors; the machine has no TPM and no passphrase fallback was planned; or the Windows edition cannot do BitLocker at all — a Windows Home machine will sit in the gap forever until it is upgraded or replaced.

Clear the list in risk order: laptops that leave the building first, then machines holding sensitive data (accounts, HR, customer records), then desktops in shared areas, then fixed desktops in controlled rooms. And verify the finish properly on every machine: status shows Encrypted and you can retrieve its recovery key from the vault. Both — not one.

Prove It — Reports, the Recovery Drill, and a Local Check

When the board is clean, pull the encryption report: which machines are encrypted, with which policy, and whether every drive's key is stored. That report is the audit proof — the difference between "we believe we are encrypted" and a document you can hand over.

Then rehearse the worst day once: pick a machine, open the console's recovery key lookup, and retrieve its key the way you would during a real lockout. Escrow you have never tested is a hope, not a system. Do the same when people change: when an employee leaves, rotate keys and access properly instead of leaving their old access and old keys live.

Sitting at one PC yourself, you can check that machine's own state from an admin Command Prompt:

manage-bde -status C:

That tells you this drive's state — it says nothing about where its recovery key lives. The vault is the answer to that second question, and it is the whole point of managing BitLocker from one console.