Forum Discussion
CSP Policy for BitLocker Encryption on AutoPilot Devices
According to the What's new in Windows 10 1809 the following functionality is available.
You can choose which encryption algorithm to apply automatic BitLocker encryption to capable devices, rather than automatically having those devices encrypt themselves with the default algorithm. This allows the encryption algorithm (and other BitLocker policies that must be applied prior to encryption), to be delivered before automatic BitLocker encryption begins.
For example, you can choose the XTS-AES 256 encryption algorithm, and have it applied to devices that would normally encrypt themselves automatically with the default XTS-AES 128 algorithm during OOBE.
I have worked through implementing this functionality with both the 1809 (17763)and 1903 (18277) builds and it does not work. The system drive automatically encrypts but the drive gets encrypted with the default XTS-AES-128 encryption.
I have the following setup.
- Windows 10 machines configured as AutoPilot devices (Windows Surface Pro 4)
- AutoPilot profiles set in Intune
- Edition upgrade policy set to upgrade to Win10 enterprise
- EndPoint Protection policy set with encryption settings for XTS-AES-256
Screenshots of the policy, the Intune errors and the BitLocker settings attached.
I have a support call logged but suggestions are welcome.
After a great deal of experimentation and a blog post from Per Larson; I tracked down the cause of the issue.
The encryption section of the EndPoint Protection policy does not correctly apply to AAD Joined devices capable of HSTI if the policy is set to Encrypt Device: Require.
I was able to successfully encrypt a device during AutoPilot with AES 256 under the following circumstances.
- Create a brand new Endpoint Protection policy (Important!)
- Apply the encryption settings that you want to set
- Make sure the Encrypt Device setting is set to Not Configured
- Apply the policy to a group containing Azure AD Joined windows devices
- Do not target the policy at user accounts
The policy settings that I used are attached.
- Andrew MatthewsIron Contributor
After a great deal of experimentation and a blog post from Per Larson; I tracked down the cause of the issue.
The encryption section of the EndPoint Protection policy does not correctly apply to AAD Joined devices capable of HSTI if the policy is set to Encrypt Device: Require.
I was able to successfully encrypt a device during AutoPilot with AES 256 under the following circumstances.
- Create a brand new Endpoint Protection policy (Important!)
- Apply the encryption settings that you want to set
- Make sure the Encrypt Device setting is set to Not Configured
- Apply the policy to a group containing Azure AD Joined windows devices
- Do not target the policy at user accounts
The policy settings that I used are attached.
- NateffromWellyCopper Contributor
Andrew Matthews Hi Andrew, quick question you have two policies attached. I would like to know how you are assigning each policy. I gather the first one is to an autopilot group that only contains devices and these settings will be applied during the OOBE/Autopilot process (Enrolment Status page). How are you applying the second policy is it to the same group and also is the does the second policy exclude the settings you have in the first ? Are you applying both policies to the same autopilot group but the settings cannot be combined in a single profile ?
- Andrew MatthewsIron Contributor
I found that most Device Restriction and Endpoint Protection settings can be applied to a user group but some settings have to be applied to a device group.
My current deployments apply BitLocker settings using a separate Endpoint Protection policy that is a assigned to an Azure AD group containing devices. I use the ZtdId trick to create a dynamic group that targets all AutoPilot devices.
- mmiadminCopper ContributorThis is an old posting which is almost 4 years back. I am having the same issue now. I am trying to encrypt the bilocker to AES256 unfortunately, the device comes with 128 encryption. The only way I was told that it could be done was to decrypt the current 128 and then re-encrypt it with 256. So, I am trying to find a solution for this. I have one PowerShell script that will try to decrypt the current 128 encryption and then I have a policy that will encrypt the 256 policy.
So, I am finding a way that we could do this. Any suggestions or thoughts or any methods?- Andrew MatthewsIron ContributorYou are on the right track. I would suggest installing a single PowerShell script onto devices as a scheduled task. There is no alternative to decrypting the drive and then re-encrypting.
A scheduled task will survive a reboot and pickup where the previous run did not complete. and avoids issues with UAC because the scheduled task runs as system.
I built a deployment system for Autopilot that includes a process to drop scheduled tasks onto devices for this type of purpose. Unfortunately that deployment system is not for public release.