Enable BitLocker Silently using Autopilot and Intune

When deploying a new Windows device using Autopilot, one of the first desired configurations is often to use Intune to automatically enable BitLocker on the Operating System Drive using TPM, and to save the recovery keys in Azure AD.  Here’s how to do just that, along with a description on why to use each setting.

Enable the ESP

Before jumping in to it, make sure that you are using the Enrollment Status Page for Autopilot. For this purpose it doesn’t exactly matter what else you configure there, but the ESP should be shown.

…but, why? When joining Azure AD you may find that Windows often turns on BitLocker automatically, even if you don’t have a policy that requires it.  This is usually due to a feature called “Device Encryption” (or sometimes “Automatic BitLocker Encryption“) which automatically protects the device under certain conditions (joining Azure AD, UEFI, TPM 2.0 and HSTI).

This feature may turn on BitLocker before the Intune policy is applied to the device, and once BitLocker is on, the policy could actually fail to apply if it has settings that differ from the defaults.  If the Enrollment Status Page is enabled, then the Device Encryption feature will wait until Intune policy assignment happens, and then BitLocker can be turned on and applicable settings can be used.

Create the BitLocker Policy

This will be done from the Endpoint Manager Portal at https://endpoint.microsoft.com

Go to Devices / Windows / Configuration profiles and then click “+ Create profile”.

The BitLocker settings are under the Endpoint protection profile type.

Give it a clever name

Encrypt devices: Require

This will enable BitLocker

Warning for other disk encryption: Block

If not blocked, a user will get a warning message about checking for third party disk encryption before enabling BitLocker.  This makes sense where you’re applying a BitLocker policy on devices that have already been deployed and running for a while, but for Autopilot deployed machines, they are coming from a virgin state where no software has been installed, let alone any disk encryption tools, so we can comfortably block this.  It also prevents the traditional BitLocker Setup Wizard from running, which is used when setting a PIN, so keep that in mind.  If you want to use a PIN you will need to leave this not configured (let’s not use a PIN for now, it’s a whole ‘nother conversation).

Allow standard users to enable encryption during Azure AD Join: Allow

For the OS drive this isn’t really necessary, but if you wanted to use BitLocker on removable media and your users were not Administrators, it would be important.  I like to enable it so BitLocker can always be used, regardless.

Configure encryption methods: Enable

You only need to enable this if you prefer not to use the default encryption ciphers. If you’re happy with defaults then leave this Not configured.

Encryption for operating system drives: XTS-AES 256-bit

Changing this from the default 128bit allows us to easily confirm that the policy was used to encrypt the disk rather than the Device Encryption feature doing it. It also is a stronger encryption which is often desirable.

Additional authentication at startup: Require

Compatible TPM startup: Require TPM
Compatible TPM startup PIN: Do not allow startup PIN with TPM
Compatible TPM startup key: Do not allow startup key with TPM
Compatible TPM startup key and PIN: Do not allow startup key and PIN with TPM

These settings are all very related and coordinating the selections is important. The BitLocker CSP documentation has a brief note that says “Only one of the additional authentication options can be required at startup, otherwise an error occurs.”  That error will be a “Policy Conflict”, because if you Require any one of these then you CANNOT Allow anything else.  So we’ll Require TPM, and set the other three to “Do not allow”.

OS drive recovery: Enable

Recovery Keys are generated by default, but we want to define what should be done with them.

Recovery options in the BitLocker setup wizard: Block

If not configured, a user could be promoted for a location to store the recovery key, or print it.  We do not want the user to do anything with it, we’ll manage the recovery for them.

Save BitLocker recovery information to Azure Active Directory: Enable

By default, an Azure AD Joined device will store it’s Recovery Key in the device object in Azure AD, but this will require it to be done.

Client-driven recovery password rotation: Key rotation enabled for Azure AD-joined devices

If the recovery key is ever used, a new one will be generated, stored in Azure AD and the old one discarded.  It effectively gives a one-time-use of recovery keys.

There are many other settings in this page for other disk types, but for this example we only want to configure the OS drive, so click Next to finish the configuration.

Assign the policy to the group of Autopilot devices.

We won’t use any applicability Rules

And finally Create the policy.

Test the Deployment

We’re ready to test the deployment either with a physical machine (ideally) or a VM.

If using a Virtual Machine, it’s important to make sure it has a TPM.  In Hyper-V, you should also consider using a Generation 2 VM.

Don’t forget to eject any ISO or Windows will see the removable media and not enable BitLocker.  It’ll also log an Error 853 in the event log as documented.

This is because the presence of Removable Media typically changes the boot process and affects the state that the TPM would need to attest to on every boot.  It is basically protecting you from encrypting the device, then later ejecting the ISO and needing to enter the Recovery Key every time you boot without the ISO attached.

manage-bde -status

Assuming you’ve already registered this device for use with Autopilot, and it is now assigned the Configuration Policy for BitLocker, it’s time to give it a try.  When you boot the machine from a fresh install (or Reset) of Windows, you can hit Shift+F10 during OOBE to get a command prompt (unless the device s in S mode).  Here we can confirm that BitLocker is NOT turned on yet.

Proceed through Autopilot to provision the device.

Once on the desktop, open an elevated command prompt and confirm that BitLocker is on and encrypting the drive with the Method you set in the policy.

After just a few minutes encryption should be complete.

When looking at the Device configuration list in Intune, you should see the BitLocker policy applied successfully.

Each setting in the policy can be verified as well.  If there was an error you can see which part failed here and do some troubleshooting.

You can also see the Recovery Keys that have been backed up to this device object.  In this example I have several keys because I deployed it with Autopilot a few times for demos.  The most recently generated key will be at the top.

manage-bde -protectors c: -get

You can confirm the key in the portal matches the key on the device

As an end user, they can also get their Recovery key from https://myaccount.microsoft.com and selecting their Device.

The users can access that same portal from any device they can authenticate with, including their phones, enable self-service key recovery so your help desk team doesn’t need to have access to the keys or read them off to someone on a call.  An authorized user would be able to get it themselves.

I hope that helps!

23 thoughts on “Enable BitLocker Silently using Autopilot and Intune

  1. Thanks for such a great and wonderful post Mr.Shannon. It really helped in understanding each and every setting available. I do have a quick question about recovery key retrieval by and end user through https://myaccount.microsoft.com. Does the device need to be only Azure AD joined? We have hybrid Azure AD joined devices in our environment and I couldn’t find my device that I encrypted in the portal and hence couldnt retrieve the recovery keys, Although they are being saved in Azure AD.

    1. Hybrid Joined Machines can store their keys in AAD, but they are really a AD Domain Joined machine first, and then the device registers itself in Azure AD. Since this Hybrid Join process is performed by the device (not the user), the registered device in AAD does not have an “owner” (this is technically different from the Intune or “primary user”). The myaccount portal allows a user to see the recovery keys of the devices they are owners of, and therefore they cannot see any Hybrid Joined devices because they are technically not the owners. In some cases the Intune Primary User will also set the AAD Owner property, so you might try changing the primary user if the devices are Intune managed (or co-managed) and see if that exposes the keys to that user. https://docs.microsoft.com/en-us/mem/intune/remote-actions/find-primary-user

  2. Thanks so much for your post. I’m struggling to achieve “Fully Encrypted” versus “Used Space Only” when trying this exact same policy with my Azure AD joined laptops. I was hoping your information on only choosing one of the TPM options was my problem but even after fixing that and matching your screenshots, my laptops still end up with “Used Space Only” encryption. We are required to encrypt the entire drive and I’m wondering if you have any suggestions as to what I may be missing they you did to get there. Thanks!

    1. No, as I recall there are no Intune controls to set the Encryption Type to “Full”. BitLocker Preprovisioning is hardcoded to just encrypt the “Used Space Only”.

      There is a registry key called “OSEncryptionType” that is supposed to control this, and there are GPO’s for that, but it only matters for already deployed, unencrypted devices that use an Agent like MBAM (or ConfigMgr) to be used when they enable BitLocker post-deployment. Regardless, I also tried to ingest the VolumeEncryption.admx template to set it with a Custom policy, but the registry path is blocked from CSP changes, so that didn’t go real far.

      Another thing I remember experimenting with, but can’t recall if it worked, was creating a powershell script that would set that key, then assigned it to the device via Intune. The trick is getting the script to run in SYSTEM context so it can write to the correct Registry hive. I think I used Oliver’s powershell template to do that. https://github.com/okieselbach/Intune/blob/master/ManagementExtension-Samples/IntunePSTemplate.ps1

      Here’s the command to set the key.
      Set-ItemProperty -Path “HKLM:\\Software\Policies\Microsoft\FVE” -Name “OSEncryptionType” -Value 2 -Type DWORD -Force

      All that said, maybe don’t do that. In lieu of encrypting the free space, you could use “manage-bde -wipefreespace” to ensure whatever is in the unencrypted parts of the disk are removed. “Running this command on a volume encrypted using the Used Space Only encryption method provides the same level of protection as the Full Volume Encryption encryption method.”

  3. I’ve noticed that a few of my devices during OOBE start encryption using 128-bit when my policy is set to 256. We are seeing this almost 1 out of every 3 we step though. Any thoughts?

    1. Usually this is happening because “Device Encryption” is kicking in and turning things on with default settings. Make sure your devices are using Autopilot and you have the Enrollment Status Page turned on. That’ll force the device to wait in OOBE at the ESP to get Intune policies before proceeding with other defaults.

    1. Sure, I’ve personally deployed Hyper-V VMs using Autopilot hundreds of times. It’s a great way to do testing because you can use checkpoints to skip the reset time. Some things like Self-Deploy mode do not work (by design) on VMs but User-Driven mode work just fine.

  4. If you enforce BitLocker via a configuration policy how do you address encryption in your compliance policies? If encryption is “required” in the compliance policy then at the time of user driven enrollment the compliance policy will show the device as non-compliant and therefore not proceed with applying the configuration policies. Just looking to understand how to properly enforce BitLocker and continue to check that it is enabled to allow access to company resources.

    1. Great question Bob. You’re right, a Compliance Policy would show a device as Noncompliant while it’s still encrypting the drive. To prevent that you can set a Grace Period on the compliance policy. In the “Actions for non-compliance” you can set the “Mark device noncompliant” action and define the Schedule to some numeric value. It’s represented in a number of days, but you can use decimals to set a fraction of a day. For example, use 0.33 days to mark a device as non-compliant in ~8 hours. That gives newly deployed devices a chance to “settle up” their configurations and attest to their state before they would be subjected to the Conditional Access policies that require Compliant devices.

  5. You’ve answered a lot of questions I’ve struggled with for nearly two months – thank you! However, I’m still running into conflicts with byod devices that do not have a TMP chip. Any advice here MrShannon?

    1. I haven’t had to deal with this one myself, and I would also suggest that not requiring a TPM is not a great idea because you give up any hardware attestation of the health state of the device.. So I would not want to allow it…but I get it, there are reasons, Not usually BYOD reasons, but I’ve heard some. Regardless…

      The Settings Template does allow you to Require “Additional authentication at startup” and you can leave “BitLocker with non-compatible TPM chip” as Not Configured, then choose what methods to Allow (but not not Require any of them). For example:

      Compatible TPM startup: Allow TPM
      Compatible TPM startup PIN: Do not allow startup PIN with TPM
      Compatible TPM startup key: Allow startup key with TPM
      Compatible TPM startup key and PIN: Do not allow startup key and PIN with TPM

      I’m not certain, but I believe the example above will still require a TPM, but it can be used with or without a startup key (I’ve seen this used for making PINs optional for example). The trouble here is really the setting “BitLocker with non-compatible TPM chip” which, in the Template, only allows states of “Blocked” or “Not configured”. According to the BitLocker CSP docs (below), “If you want to use BitLocker on a computer without a TPM, set the ‘ConfigureNonTPMStartupKeyUsage_Name’ data.”


      Normally that would mean creating a Custom CSP with your BitLocker settings, because the UI for the setting in the Template doesn’t provide a way to set the data to anything other than Blocked (false) or Not configured. If you wanted to do the same thing as listed above, but actually allow “BitLocker on a computer without a TPM”, A custom CSP that matches the list above might look something like this:

      After that, you’d also need to define your other BitLocker settings, either manually in this same custom CSP or in separate Template policy with no conflicting settings. And that’s pretty fun (messy!). However, now that the Intune Setting Catalog is available, you might have a new option.


      Rather than using the “Endpoint Protection” template, try using the Settings Catalog to set “Allow BitLocker without a compatible TPM (requires a password or a startup key on a USB flash drive)” to TRUE. Under the covers, this is the same policy setting, but where the Template can only Disable or ‘Not Configure’ it, the Catalog can Enable, Disable or “Not configure” it.

      Anyway, I hope that helps, but I also hope you don’t do it ;] Maybe get some devices with TPM instead. Good luck!

  6. Where would you say is the best place to set up BitLocker?
    Endpoint Security > Security Baselines
    Endpoint Security > Disk encryption
    Devices > Configuration profiles

    1. Like most things, it depends. The biggest driver of this will come down to organizational management. Who owns what often drives where policy enforcement happens. Truth is you can use any and all of those things, but I think you’ll find each of the Baseline policies have only a few settings compared to the actual Configuration profiles. This is absolutely intentional however, as the audience for the Baselines vs Configurations are generally different roles (teams of people) in an organization. The Security teams are usually looking for a broader company-wide (baseline) policy that meets some business policy, and the Configuration team is looking for all the knobs and levers that will help them enforce a stated company agenda.

      For example, the Security team may want to declare that “no one can write to removable media unless it is encrypted”, which is the only BitLocker thing that can be done in the Security Baseline. But they may also want to say “All devices use 256bit encryption on OS drives” which they can do in the “Disk Encryption” policy.

      Under the covers, all three places you pointed out send the same CSP/SyncML to the device, so you’re just using different “views” to set the same things. And as long as the settings in multiple policies don’t conflict, you’re good to assign as many as you want.

      Keep in mind that Intune does not do any kind of conflict resolution. So if you do mix and match where you set policies, you must be judicious about using the same values, or be sure to use ‘Not Configured’ when overlapping any settings between different policies to avoid conflicts. If a conflict is found, that setting does not apply, and you’ll just get a error to fix it.

      Bottom line: I personally find myself using the Configuration Profiles over the baselines, usually because the Security Team is not often making the actual policies that get applied that to devices, but rather they are defining the “company policy” that influences the chosen settings. Then the company has a different endpoint management team that is actually creating the configuration policies that get assigned to the devices, and they own the tactics to make sure the devices meet that company policy. And, now that we have a new choice, I think I would use the Settings Catalog instead of the Templates.

      I hope that helps!

  7. any option to enable bitlocker silently (or not) with hardware with TPM 1.2, Today my encryption is failing in those computers. Regards.

    1. TPM 1.2 or 2.0 should work fine when using an Intune policy. To use the “Device Encryption” feature, which is the auto-enablement of BitLocker without a policy, that requires TPM 2.0. Depending on the device, you might be able to upgrade the TPM with a firmware/uefi/bios update, and if you can, you probably should. Oh, and disable BIOS and make the switch to UEFI only too.


  8. Hi MrShannon,

    I’m experiencing some problems with a laptop that i’m testing with.

    I used your guide to enroll Bitlocker. Ans on top i used windows 10 in cloud configuration.
    Now i have 2 issues:
    1. My policies said that it succeeded, but bitlocker isn’t turned on, on my laptop
    2. Even though i said that standard users can rollout bitlocker, my user can’t access bitlocker on the local machine.

    Could you help me figure this out?

    Hope to hear from you.

    1. If you used Cloud Config it’ll create some Intune Policies and assign them to groups for you. You can also create your own policies and assign them to the same groups, but you’ll need to make sure you don’t have ANY settings in these assigned polices that conflict. For example, if Cloud Config sets the encryption type to 128 and you make a policy that says 256, they’ll conflict and settings will not be applied. You might have some comparisons to make or look for errors to look at and resolve any conflicts yourself.

      Also, Cloud Config will set your users to be Standard accounts, which means they will not be Administrators and cannot use some of the tools like manage-bde or open some of the control panels. You can circumvent this by logging in to the machine with a local admin account or an AAD account that has the Global Admin or Device Admin role.

  9. Nice article. In the configuration policy assignment do we have to add the users group or devices? Lets suppose we get new laptops without users login to autopilot how do we know the name of machine to add in group? ESP has one default policy do we need to turn that on or create the new policy?

    1. Assign the policy to a group that the Device will be a member of. I like to use a Dynamic Group that finds devices with a particular Autopilot Group Tag. That way whenever a device is registered for Autopilot it gets a set of policies that I want for that tagged “group” of devices, and then the machine name doesn’t matter and it doesn’t matter who signs into the thing. It also works with self-deployed devices too.

      You can create one group that will find ALL Autopilot devices. This is a little dangerous because it doesn’t matter what Group Tag you use, any device that is registered for Autopilot will be in this group, so be really careful about what policies you might assign here as every autopilot device will have to deal with it.
      (device.devicePhysicalIDs -any _ -contains “[ZTDId]”)

      You can also create a group that just finds devices with a specific group tag (aka: OrderId, not be confused with PurchaseOrderId, a different property). This is handy because you can create tags for different device types or usage scenarios, like devices for “Sales” or “Developers” or “Kiosks” and so on. You can then be more prescriptive about targeting policies to each use case.
      (device.devicePhysicalIds -any _ -eq “[OrderID]:MyGroupTagHere”)

      More examples are in docs https://docs.microsoft.com/en-us/mem/autopilot/enrollment-autopilot

      1. Thank you so much. It makes sense. One question other than autopilot if we use the DEM account to enroll all the devices and change the primary user and management name for each device in Intune. In this case how the compliance policy works? like compliance policy will be applied to enrolled by user (DEM) or primary user. We have a bitlocker compliance policy (require bitloker) and setup the configuration profile followed the steps you mentioned and it worked fine. I added the users group in the configuration policy assignment. I am not sure how it will work with DEM account. Please advise.

  10. Is there a way to create the dynamic device group with a join type or any similar solution. Let’s suppose I add the device group in the configuration profile assignment. Any device that joins with Azure AD will be automatically added in the group and apply the policy instead of adding manually.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s