Intune Silently Enable BitLocker

2023年5月28日 LOG admin

原文：Intune Silently Enable BitLocker — theDXT (Daniel Keer)

When you are managing devices with Microsoft Intune aka Microsoft Endpoint Manager it’s great to control BitLocker but silently enabling BitLocker for all devices is even better.

Here is everything you need to know to silently enable BitLocker with Intune.

What “Silent” Actually Means

BitLocker on a managed Windows device can start in two very different ways. The first is interactive: Windows shows the “Turn on BitLocker” wizard, the user chooses where to store the recovery key, and encryption only begins after they click through the prompts. The second is silent: a mobile device management (MDM) policy sets the device management flags that tell BitLocker “this computer is managed, encryption is required, do not ask the user anything”, and the operating system starts encrypting the OS and fixed drives in the background at the next policy refresh. No wizard, no notification, no user decision, and no support call asking which drive is which.

The mechanism underneath is the BitLocker configuration service provider (CSP). Intune has no single “turn BitLocker on” switch; it has a group of CSP nodes that shape how BitLocker behaves, plus one node that makes encryption mandatory. Silent enablement is the combination of:

RequireDeviceEncryption = 1, delivered by the Endpoint protection configuration profile setting Encrypt devices: Require.
The wizard-suppression settings, delivered by the disk encryption policy profile: hide the third-party encryption warning, allow standard users to start encryption, and define the encryption method for each drive class.

Two objects therefore have to be assigned to the same devices. Assign only the configuration profile and you get an interactive prompt instead of silent encryption. Assign only the disk encryption profile and nothing at all happens — which is exactly the behaviour described in the original article. The next two sections build both objects in the order that avoids that trap.

Prerequisites Before You Build Anything

Licensing: Intune is included with Microsoft 365 E3/E5 and EMS E3/E5, or sold standalone. There is no separate BitLocker licence, but the compliance and conditional access tie-ins described later are most useful with an E3/E5 bundle, and some enrollment scenarios expect Entra ID P1.
Windows edition: full BitLocker is a Windows 10/11 Pro, Enterprise and Education feature. Windows Home ships “Device Encryption”, which is BitLocker-based but is not driven by the full BitLocker CSP; target a Home device with these policies and it will simply do nothing visible.
Join state: Entra ID joined or Hybrid Entra ID joined. Recovery key escrow to Entra ID needs a device object in Entra ID, so a classic AD-only domain-joined machine that never hybrid-joined cannot escrow keys regardless of policy.
Hardware: TPM 2.0 preferred (TPM 1.2 works with restrictions). UEFI firmware with Secure Boot recommended. Verify with Get-Tpm and msinfo32 before you blame the policy.
Disk layout: drives must be NTFS, with the standard system partition created by Windows Setup and enough free space for the BitLocker metadata. A machine whose recovery partition was moved or resized by hand is a common source of silent failure.
MDM enrollment: enrollment must have completed and the device must be checking in. dsregcmd /status should show AzureAdJoined : YES plus a valid MDM URL.
Single management authority: do not drive the same device from Intune and a third-party MDM, and check for leftover on-premises Group Policy objects that write the same FVE registry keys.

Disk Encryption Policy Profile

First up we need to create a disk encryption policy profile that we can use later on with our configuration profile. The Disk Encryption Policy Profile by itself really does nothing other than defining the settings that will apply when referenced by a configuration profile.

Login to Microsoft Intune admin center
Click on Endpoint Security

Click on Disk encryption

Click on Create Policy

The naming is conflicting because now it’s called a profile. Let’s just call it a Policy Profile to keep things simple.

Set the Platform as Windows 10 and later and the Profile as BitLocker

Give your BitLocker Policy Profile a name. I’m going to call mine BitLocker Policy Profile

Set the following options for BitLocker – Base Settings
- Set Enable full disk encryption for OS and fixed data drives to Yes
- Set Hide prompt about third-party encryption to Yes
- Set Allow standard users to enable encryption during Autopilot to Yes
- I’m going to set Configure client-driven recovery password rotation to Enable rotation on Azure AD and Hybrid-joined devices but you should set it to your preference.
Set the following options for BitLocker – Fixed Drive Settings
- Set BitLocker fixed drive policy to Configure
- Set Configure encryption method for fixed data-drive to AES 128bit XTS. (This is the default setting, you can change it to whatever you want)
Set the following options for BitLocker – OS Drive Settings
- Set BitLocker system drive policy to Configure
- Set Configure encryption method for Operating system drives to AES 128bit XTS. (This is the default setting, you can change it to whatever you want)
Set the following options for BitLocker – Removable Drive Settings
- Set BitLocker removable drive policy to Configure
- Set Configure encryption method for removable data-drives to AES 128bit XTS. (This is the default setting, you can change it to whatever you want)
After you’ve set all of that click Next

BitLocker Policy Profile Settings

Set your Scope tags if applicable and click Next

Select the device groups you want to target this BitLocker Policy Profile to.

I like to use some of my dynamic device groups for this. You can read more about the dynamic device groups I like to use in my post called Intune Dynamic Device Groups

When you select the groups this won’t actually make any of the settings take effect. We are just defining the settings so that a configuration profile can reference them. Which is the next part.

Review the BitLocker Policy Profile you’ve drafted if everything looks good click Create

Configuration Profile

Now we can create the BitLocker Configuration Profile that will apply to the devices which will reference the BitLocker Policy Profile we just created.

Click on Devices

Click on Configuration profiles

Click on Create profile

Set the Platform as Windows 10 and later set the profile type as Templates and select Endpoint protection

Give your Profile a name. I’m going to call mine BitLocker Configuration Profile

Under Windows Encryption set the following settings
- Set Encrypt devices to Require
- Set Warning for other disk encryption to Block
- Set Allow standard users to enable encryption during Azure AD Join to Allow

We don’t need to configure our encryption methods because that’s already taken care of in the BitLocker Policy Profile we created.

I like to enable additional authentication at startup as Required to be extra secure but you don’t need to set that setting.

Select your Assignments

This is where selecting only the corporate owned devices is very important as you have told it to enable BitLocker even if the device is using some third party encryption which can cause issues if a user has VeraCrypt or something else also enabled. I will use my Intune Dynamic Device groups to make sure my targeting is on point.

Set your Applicability rules if applicable

Review the draft BitLocker Configuration Profile if all looks good click Create

That’s all it takes. If you set the settings correctly your devices will now start silently enabling BitLocker.

Recovery Key Escrow, Rotation and Reporting

A silent encryption with no escrowed recovery key is a support incident waiting to happen. The user never saw a recovery key, so if BitLocker ever asks for one at boot there is no answer to give over the phone. Escrow is not optional in a silent deployment — it is the whole safety net.

Escrow target. The disk encryption profile option that saves recovery information to Entra ID is what puts the key in the cloud. Hybrid joined devices can additionally escrow to on-premises Active Directory, which requires the AD schema extension and correctly delegated permissions — a directory team task, not an Intune task.
Where to find keys. In the Intune admin center: Devices → All devices → pick the device → Recovery keys. In the Entra admin center: Devices → All devices → the device → BitLocker keys. Both surfaces read the same Entra ID escrow record.
Automating key retrieval. Microsoft Graph exposes the escrowed keys: list the recovery keys for a device with the informationProtection/bitlocker/recoveryKeys endpoint filtered by device id, then request the key value itself with the key selector. The app registration needs the BitLocker recovery key permission (application or delegated) plus admin consent — handy for a helpdesk portal, and worth reviewing before you publish anything that can read every key in the tenant.
Rotation. Client-driven recovery password rotation is the single highest-value BitLocker setting for organisations that keep keys in a helpdesk console. When a recovery key is used to unlock a drive, the client generates a fresh recovery password, escrows it, and the old key expires about 24 hours later, so a key that was read out loud during an incident stops working. The original profile above enables rotation on Entra and hybrid joined devices; disable it only if a downstream tool cannot tolerate the keys changing.
Reporting. Intune → Reports → Encryption report (also reachable from Endpoint security → Disk encryption) shows per-device encryption state, which volume classes are encrypted, and readiness blockers such as a TPM that is present but not ready, or third-party encryption being detected. This is the report to watch during a pilot.

Third-Party Encryption and Why Scoping Matters

The disk encryption profile setting Hide prompt about third-party encryption = Yes is what makes silent enablement silent — and it is also what makes failures invisible. With the warning suppressed, if BitLocker detects another encryption product already in play (VeraCrypt, a commercial full-disk encryption agent, or an OEM pre-provisioned drive) it does not prompt, and it does not encrypt. The user sees nothing. Intune may even report the device as encrypted, because the drive is encrypted — just not by BitLocker, and therefore not with a key you can recover.

That is precisely the risk the original article flags, and it is why the assignment scope deserves as much care as the settings:

Target corporate-owned devices only. A device filter scoped to (device.deviceOwnership -eq "Corporate") keeps the policy off personally owned hardware with the least administrative overhead.
Exclude BYOD explicitly. For personal devices either leave BitLocker alone, or use a second profile with the third-party warning set to No (that is, prompt enabled) so the user makes an informed choice.
Keep group membership deterministic. Device filters and tight dynamic device groups avoid the classic “the policy applied to my test machine because someone added it to the pilot group” problem. The related posts below cover both mechanisms.
Never mix “Hide prompt” with a device population you cannot inventory. If you cannot say which of the targeted machines run a third-party encryption agent, you are not ready to hide the prompt.

Verifying That Encryption Really Started

Do not trust the console alone. These commands on a pilot device answer the two questions that matter: is the drive actually encrypted, and did the MDM policy actually land?

# Protection state and progress, per volume
manage-bde -status
Get-BitLockerVolume | Select-Object MountPoint, VolumeStatus, ProtectionStatus, EncryptionPercentage

# Which key protectors exist (TPM, recovery password, startup key)
manage-bde -protectors -get C:

# The MDM BitLocker policy that actually landed on the device
Get-CimInstance -Namespace root\cimv2\mdm\dmmap -ClassName MDM_BitLocker |
    Select-Object RequireDeviceEncryption, AllowStandardUserEncryption,
                  AllowWarningForOtherDiskEncryption

# Join state and MDM enrollment
dsregcmd /status

How to read the output:

VolumeStatus: FullyEncrypted with ProtectionStatus: On and an encryption percentage of 100 means the job is finished and the key protectors are active.
VolumeStatus: EncryptionInProgress with any percentage between 1 and 99 means it is working. A large drive on a busy laptop can take a long time, and the percentage can appear stuck while the machine is in use — that is normal, not a fault.
A recovery password protector that is not escrowed means key backup silently failed. Check join state before blaming Intune.
No RequireDeviceEncryption value at all means the configuration profile has not been delivered yet. Force a policy refresh from Settings → Accounts → Access work and school → Info → Sync, then re-check.

Troubleshooting Silent Enablement

Requirement delivered, nothing encrypted. Check whether the signed-in user is a standard user and whether Allow standard users to enable encryption is on. Without it, a standard-user session leaves the OS drive unencrypted until an administrator signs in and the policy re-evaluates. There is no error dialog — the device just never becomes encrypted.
TPM present but not ready. If Get-Tpm reports the TPM is not ready or not owned, fix the firmware problem first. Encryption without a usable TPM needs a startup key or startup PIN, which is a different user experience.
It started, then stopped. A pause near zero percent usually means free space, a failing disk, or a competing disk filter driver. Check the BitLocker operational log before changing policy.
Compliant before you ever assigned the policy. Some OEM images ship with the drive already encrypted, and Windows may have enabled Device Encryption automatically. Confirm with the protectors list rather than the compliance state.
Policy conflict. Legacy Group Policy that turns BitLocker off, or a leftover MDM authority, can override the Intune values. Check the resulting policy set rather than the intended one.
Non-compliance right after Autopilot. Encryption can only start once the device has received the policy, so the enrollment status page may finish before the drive is protected. If a compliance policy requires BitLocker, expect a short, harmless period of non-compliance on first boot.

Compliance and Conditional Access Tie-In

Silent enablement becomes enforceable when it is paired with a compliance policy. A Windows 10/11 compliance policy that requires BitLocker marks the device compliant only while protection is on, and a Conditional Access policy can then require a compliant device for access to Microsoft 365 — which closes the loop: no prompt, no user delay, and by the time the user opens mail and Teams the device already satisfies the rule. Test such policies in report-only mode before enforcing them, and use the What If tool to see exactly which policies would apply to a given sign-in.

Rollout Checklist

Confirm Windows edition, TPM readiness and join state on one pilot machine.
Build the disk encryption policy profile, and decide the key escrow and rotation options deliberately for each join type.
Build the Endpoint protection configuration profile with Encrypt devices: Require.
Assign both profiles to the same corporate-owned device group, or scope them with a device filter on device ownership.
Confirm pilot recovery keys appear in Entra ID before widening the group.
Watch the Intune encryption report for readiness blockers during the pilot.
Add the compliance policy and Conditional Access rule last, and enable them in report-only mode first.

Get the order right and the whole deployment is invisible to the user, which is the point: the machine is encrypted from the first sign-in and nobody had to make a decision about it.