A Beginner’s Guide to Managing BitLocker with Intune

Looking to deploy BitLocker with Intune but don’t know where to start? This is one of the most common places people start when first getting into Intune. In this beginner’s guide, you’re going to learn everything you need to know about using Intune to manage BitLocker including recommended settings, how the BitLocker CSP works on the client, and tips if you are migrating from an existing solution.

Update May 2024: Intune now uses the Settings Catalog template (version 2) for the BitLocker profile.

Prerequisites

Before we jump into configuring, let’s take a look at the prereqs:

• A valid Microsoft Endpoint Manager (Intune) license
• Devices must be Azure AD or Hybrid Azure AD joined
• Devices must not be encrypted with third-party disk encryption like McAfee Disk Encryption or WinMagic. You will need to fully decrypt those first.
• Devices can be already BitLocker encrypted and managed with things like MBAM or McAfee MNE. We’ll go into more detail on how to deal with this.

For silent or automatic BitLocker enablement, which will be the focus of this blog, you’ll need a few more things:

• The device must have a TPM chip at version 1.2 or higher (TPM 2.0 strongly recommended)
• BIOS must be set to UEFI
• If the signed-in user is a standard user then Windows 10 1809 or newer is required. If they are a local admin then Windows 10 1803 or newer is required. Since those versions are no longer supported then as long as you are on a supported version of Windows 10 or Windows 11 then you are good.

Where to Configure It

Over the years, where you configure BitLocker in the Intune console has changed. These days, Microsoft has moved all of the “security” related items under the Endpoint Security section. While you can still configure BitLocker under the Settings Catalog or via custom-URI, the best practice is to set up everything under Endpoint Security.

Go to Endpoint Security > Disk Encryption > Create Policy.

Under Platform select Windows 10 and later > BitLocker.

What settings should you set?

When you get to the configuration settings page, you may be overwhelmed with the number of different settings that you can configure. Which ones are critical to set vs. which ones are optional or just “nice” to have? Let’s break it down.

Section 1 – BitLocker

The first section is where you configure silent enablement and enforcement of BitLocker. The first setting, “Require Device Encryption” is what forces BitLocker to be silently turned on. The setting “Allow Warning for Other Disk Encryption” is what hides or shows the UI about encryption to the end-user. Additionally, you can allow the silent BitLocker enablement to work on for a standard user in addition to an administrator. You can also set up automatic rotation of BitLocker keys. I recommend the following configuration:

Specifying BitLocker Drive Encryption Types

This section is for configurating the encryption method and strength for the 3 types of drives — removable drives, OS system drives, and fixed data drives.

I recommend the highest encryption method of XTS-AES 256-bit. The setting “Provide the unique identifiers for your organization” is a bit niche and most likely won’t be used. Hover over the information bubble if you need this.

Operating System Drives

This section gets into more granular settings for the operating system drive. The most common setup I’ve seen used in the industry (and also used personally) is with TPM but no PIN. Most of the settings I’ll recommend will be based around that.

Enforce drive encryption type on operating system drives: Enabled, Used Space Only encryption. This ensures that encryption is turned on automatically and it will make the initial activation of encryption go a bit faster. Keep in mind that there is some default behavior on Windows even if this is not set. See this MS article for more details.

For the next handful of settings, we want to “Require TPM” and disable the use of startup key and PIN.

Since we aren’t configuring PIN, the next batch of settings will remain set to “Not configured”.

The next grouping of settings has to do with recovery. The “data recovery agent” (DRA) is an optional tool to recover data when the drive is mounted on another system. You don’t have to use a DRA to recover data though, as you can use the 48-digit recovery key. You can read more about DRAs here.

For Preboot recovery message, set up something basic without giving out too much org-specific information. Don’t put your company name or direct help desk number. Employees should already know how to contact the help desk and putting the number directly there will make it easier for an attacker to try to call and phish for the recovery key.

For Preboot recovery URL, I normally don’t set this up as I don’t find it particularly useful enough for end-users to be able to actually use.

For recovery key backup, the wording here indicates only backing up to ADCS. Note that if a machine is Hybrid joined or Entra AD joined, it will also attempt to back up the key to Entra AD as well in addition to ADCS. For more information on this, see these two articles:

BitLocker Recovery Guide

Autopilot and BitLocker

Next, rinse and repeat test settings for the “Fixed Data Drives” section.

Removable Drive Settings

For final section, configure as needed per your organization’s requirement. In my case, I usually leave these “not configured”.

Now you can complete the wizard to save and assign out to your devices.

A Look at How they Apply to the Client

Intune uses the BitLocker CSP to apply all of the settings to the client. This CSP is a little complicated though. First, most of the settings are “ADMX-backed” which are basically traditional GPOs sent down via the MDM channel. You can read more about them here. Here’s a crash course though:

First, go to this path in the registry: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PolicyManager

Then expand the node: Current > device > BitLocker.

You’ll notice that each setting has 3 nodes just for one thing. For example, the EncryptionMethodbyDriveType has:

EncryptionMethodByDriveType_ADMXInstanceData
EncryptionMethodByDriveType_ProviderSet
EncryptionMethodByDriveType_WinningProvider

Or

ConfigureRecoveryPasswordRotation
ConfigureRecoveryPasswordRotation_ProviderSet
ConfigureRecoveryPasswordRotation_WinningProvider

The ones with “ADMXInstanceData” reference different settings where the values are configured. If you take the GUID saved under one of the keys with “_WinningProvider” at the end (in my case it’s 4480E943-0A38-467C-BA94-18172A839761). Then expand the “providers” node, find that same GUID, and then expand again you’ll see the actual values of those settings. You can open the ones that start with “<enabled/>..” and copy/paste into notepad for easier reading.

You can also just open up one with ADMXInstanceData and it has the full path as well. For example, if I open up EncryptionMethodByDriveType_ADMXInstanceData, the full path to where that is configured is: Software\Microsoft\PolicyManager\providers\4480E943-0A38-467C-BA94-18172A839761\default\Device\BitLocker.

The important thing to know is that these settings also get converted and set in the traditional GPO area: HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\FVE

You can monitor the success or failure of these settings in the Intune console under the Profile Overview section. If you click on the BitLocker profile under Endpoint Security > Disk Encryption. You’ll see a pie chart with the overall details:

Note: You are going to see a much higher number under devices in that pie chart than are actually deployed. This is because Intune counts both the device and user each as a separate item.

Where to Check for Errors

If you click on the pie chart or either the “Device Status” or “User Status” sections on the left-hand side, you’ll quickly notice that you can’t “sort” or “filter” on any of these columns like you can other areas of the console. Bummer. So how do you locate those devices that have errors like the 2 devices shown above?

One way is to click on the device status and then click “Export” at the top of the list. This will export all of the devices and then you can sort and filter that way.

A better way though is to go under the “Monitor” area under Devices. Click on Devices > Monitor.

Then Assignment Failures (Preview). Find your BitLocker profile and click on it. Now it will show you just the devices that have failures.

Then click on one of those devices and you can drill down to see which particular setting it is failing on.

Microsoft has a pretty good article on troubleshooting BitLocker encryption on the client-side so it’s worth checking out. You can also see the majority of BitLocker errors in the event viewer. Navigate to Microsoft > Windows > BitLocker API > Management.

Or you can query this log with PowerShell:

Get-WinEvent -LogName "Microsoft-Windows-BitLocker/BitLocker Management" -MaxEvents 100 |sort TimeCreated | ft -AutoSize -Wrap

One last place you can check on the client to see whether the BitLocker settings are successfully applying is by going to Task Scheduler. Navigate to Microsoft > Windows > BitLocker and then select “BitLocker MDM Policy Refresh” scheduled task.

This scheduled task is what Intune uses to enforce the BitLocker MDM policies on the client. Click on the “History” tab, and you can see any errors here:

Deploying to Already Encrypted Devices

So what happens if you need to deploy this to already BitLocker-enabled systems? Thankfully this is fairly straightforward, but there are a few things to be aware of:

Devices will not decrypt and re-encrypt

If you deploy this profile to a device that is already BitLocker encrypted, the settings will successfully apply but nothing will happen to the encryption itself. It will remain encrypted as it is. This applies if you configuring the encryption method that matches what is already there, i.e. XTS-128 > XTS -128, or if you have a different method, i.e. XTS-128 > AES-XTS-256.

The only way you will be able to have the encryption method that you set in your profile is to fully decrypt and re-sync Intune which will automatically re-enable BitLocker with the target encryption method.

Remember that you can actually deploy a different encryption method than the one current in use on the device. In my case, the bulk of our devices where encrypted AES-256 and we deployed the Intune profile as AES-XTS-256 with no problems. We did not fully decrypt and re-encrypt existing devices (although we could have), but all net new devices will get the more secure AES-XTS-256 method.

Recovery Keys will Not Escrow to AAD

This is one of the things that I wish Intune would change. It does not automatically escrow any keys already on the device. This means you will have to manually escrow them using the BackupToAAD-BitLockerKeyProtector PowerShell command. Here is a great blog that can get you started with a sample script to escrow the keys.

This command actually backs up the key to Azure Active Directory. BitLocker keys are stored in AAD and not actually in Intune. Intune simply calls the API to Azure to query the key so that you don’t have to leave the Intune console.

I go through a lot more detail on migrating from another BitLocker management tool (like McAfee MNE) in my blog here so be sure to check that out if you need to migrate from another tool.

A Few More Things You Should Know

Before rolling this out broadly to your devices, be sure to check out my other blog that talks about a few more things you should know. It will save you time!

Wrap Up

Now you know how to get started with managing BitLocker with Intune. You’ve learned what settings are worth configuring in the profile, how it works under the hood on the client, and where to look if you run into errors.