Bitlocker Failing to encrypt Error: -2016346112 (No Error Code)

Brass Contributor

I'm just learning Intune and I'm setting up everything for the first time. I setup BitLocker I have my settings below. On my Virtual machine that I connected with Autopilot, Bitlocker encrypted the drive just fine (even though I get the same error code above).  What I mean is, I can look in the Virtual Machine and it shows the drive is encrypted fine.

 

For my desktop/Physical machine, however, it is not encrypted and I get the same error. If I go into the Device information and click on the properties all the settings are successful except for "Encrypt Devices" and that has a state details of: -2016346112 (No Error Code) If I click on that line the sidebar comes out and it says error code: 0x87d10000

 

Searching on the Internet reveals ZERO answers. I'm not sure what is going on here. Can anyone shed some light on this?

 

Edit: I should mention my desktop has two Hard Drives. I don't know if that matters.

Edit 2: I am running TPM 2.0 it is a new dell mfg'd in December.

17 Replies
The Intune portal doesn't give you the feedback you need.
Have you searched in the Event Viewer within the 'Bitlocker' events to check for certain errors?

@Thijs Lecomte I did search on the Application and Security logs and found nothing.  Under the "Applications and Services Logs" -> Microsoft -> Windows ->Bitlocker-API and Bitlocker-DrivePreperationTool there is nothing. The latter is completely blank and the former has only informational logs saying this:

 

The following DMA (Direct Memory Access) capable devices are not declared as protected from external access, which can block security features such as BitLocker automatic device encryption:


ISA Bridge:
PCI\VEN_8086&DEV_0697 (Intel(R) LPC Controller (W480) - 0697)

PCI-to-PCI Bridge:
PCI\VEN_8086&DEV_1901 (Intel(R) PCIe Controller (x16) - 1901)

 

So, Did I just find something? Is that my issue?

I am having the same issue.  The "No error code" in Error Details is really helpful.

 

Did you happen to resolve it?

 

DLindsay_0-1610753350943.png

 

I had this myself, it's because for some reason the Standard AAD user account doesn't have permissions to perform silent encryption during Autopilot enrolment, despite being specified with the setting. It seemed to be a known issue that Microsoft were or are working on. I did this like 3 days ago so it's very recent, and it worked for me just fine.

In the end I created two separate settings, some in Endpoint security and some in Device configuration profiles.

I created the below settings in Devices > configuration profiles (Endpoint protection).

Encrypt devices
Require
Warning for other disk encryption
Block
Allow standard users to enable encryption during Azure AD Join
Allow
Configure encryption methods
Enable
Encryption for operating system drives
XTS-AES 256-bit
Encryption for fixed data-drives
XTS-AES 256-bit
Encryption for removable data-drives
AES-CBC 256-bit

I also created these settings in Endpoint security > Disk encryption.

Base:
Enable full disk encryption for OS and fixed data drives
- Yes
Require storage cards to be encrypted (mobile only)
- Not configured
Hide prompt about third-party encryption
- Yes
Allow standard users to enable encryption during Autopilot
- Yes
Configure client-driven recovery password rotation
- Not configured

Fixed drive:
BitLocker fixed drive policy
- Configure
Fixed drive recovery
- Configure
Recovery key file creation
- Allowed
Configure BitLocker recovery package
- Password and key
Require device to back up recovery information to Azure AD
- Yes
Recovery password creation
- Required
Hide recovery options during BitLocker setup
- Yes
Enable BitLocker after recovery information to store
- Yes
Block the use of certificate-based data recovery agent (DRA)
- Not configured
Block write access to fixed data-drives not protected by BitLocker
- Yes
Configure encryption method for fixed data-drives
- AES 256bit XTS

OS drive:
BitLocker system drive policy
- Configure
Startup authentication required
- Yes
Compatible TPM startup
- Required
Compatible TPM startup PIN
- Blocked
Compatible TPM startup key
- Blocked
Compatible TPM startup key and PIN
- Blocked
Disable BitLocker on devices where TPM is incompatible
- Yes
Enable preboot recovery message and url
- Not configured
System drive recovery
- Configure
Recovery key file creation
- Allowed
Configure BitLocker recovery package
- Password and key
Require device to back up recovery information to Azure AD
- Yes
Recovery password creation
- Required
Hide recovery options during BitLocker setup
- Yes
Enable BitLocker after recovery information to store
- Yes
Block the use of certificate-based data recovery agent (DRA)
- Not configured
Minimum PIN length
- Empty
Configure encryption method for Operating System drives
- AES 256bit XTS

Removable drive:
BitLocker removable drive policy
- Configure
Configure encryption method for removable data-drives
- AES 256bit CBC
Block write access to removable data-drives not protected by BitLocker
- Yes
Block write access to devices configured in another organization
- Not configured

The encryption will succeed silently and automatically, even for standard users, during the enrolment status page (ESP) and once the user signs into their device for the first time. If you haven't enabled ESP, then it won't work during Autopilot provisioning, so make sure it's been configured. The portal will display an error until it applies and starts to encrypt, which will be during the final phase in ESP. Plus, make sure any existing encryption is disabled before doing this. It can take about 20 minutes after entering the final phase in ESP for the Endpoint manager admin portal to report the profile succeeded.

Also, even though the windows event logs don't have anything, this happened to me too. I did notice that there was some information in the Windows System Information app. Scroll down until you see an entry related to encryption, that's where I found an encryption error. Although it can present strange errors so be cautious before following what it says! Mine told me to sort out the TPM but it was fine in the end.

Hope it helps.

@DavidStewart-Palapanou So on this. Do I disable the settings I had setup under Configuration Profiles other than the few you have at the top? Reason I ask is now I get error messages of "Conflict" and it says the encryption, etc is Not applicable. Presumably because the settings are already set under configuration profiles.

@Tomnibus_MedOne- Yes that's right, you should set all settings outside of the ones I've advised to "Not configured". There shouldn't be any conflicts once you're done.

@DavidStewart-Palapanou Well, darn. I went ahead and did that and it doesn't work. It still says there is a conflict.

 

I am going to double-check all the settings, I guess.

@Tomnibus_MedOne- You should be able to verify the conflicting setting by going to the device that has the conflict, selecting the setting under configuration profiles, and it should list where the setting has come from and the names of the profiles that are causing the conflict. Check the endpoint security section within the device blade as well. If you're using Microsoft Defender ATP security baseline, I think the built-in template defaults to a different level of encryption for removable media so you might find there's a conflict in there.

@DavidStewart-Palapanou Okay, I double-checked. I had to re-enable some of the settings under Configuration Profiles and then set the sub-settings to not configured, then set the main settings to not configured.

 

However, after doing that, I still get the same -2016346112 error with the error code 0x87d10000

 

Perhaps the above event viewer message about auto encryption is just that, it won't do auto encryption.

 

Oh, also, I'm a global admin and testing on a machine I am an administrator for. So the standard user thing isn't an issue for me (yet).

@Tomnibus_MedOne- Did you reset the device so that it goes through OOBE with Autopilot again after making changes? Any changes you apply won't retrospectively apply, you'll need to reset it. When your device goes through OOBE, use manage-bde -status to verify that encryption is in progress once you've logged into the device with the standard user account after setup completes all thre stages. The next time the device checks in after signing in, its status should sort itself out. It might still show that error code until OOBE has finished and the device checks in so give it ~15 minutes or so after signing in before checking.

Also you'll need to ensure that the device has been decrypted first.

@DavidStewart-Palapanou I did not because I'm attempting to install it on my Desktop machine that I have customized a lot. 🙂 I'll see what happens with some test machines.

@Tomnibus_MedOne- That makes sense. In that case, yes that'll be why there's no changes to the value you're getting in Intune. Try and build a Hyper-V Gen2 VM to test it. You'll need to ensure you have sorted the prerequisites, such as secure boot and TPM. Also, make sure there's no ISO mounted as a DVD.

 

Something like this will help:

https://docs.microsoft.com/en-us/windows/deployment/windows-autopilot/demonstrate-deployment-on-vm

This was the most helpful reply. I was getting error for "Startup authentication required", what I'd forgot to do was set these (I had left them as "Not Configured"):
Compatible TPM startup PIN
- Blocked
Compatible TPM startup key
- Blocked
Compatible TPM startup key and PIN
- Blocked
This helped me get rid of the error for a device which had been enrolled and built prior to the policy being enabled

@DavidStewart-Palapanou  So we have had the same issues as above, bur can i just change/move my settings to endpoint security without direct impact on currently active PCs and users? This changes will hit first after reset and OOB? 

 

Thanks!

@PerkarlLindb Any changes you want to apply will apply to the assigned users/devices at anytime, even if they have already completed OOBE. I would recommend isolating the changes to a single device/user if you are transitioning from one set of settings to another. If you are like-for-like transitioning, then theoretically, it should just work and it will take effect on existing PCs already enrolled, and new enrolments which undergo OOBE.

Thanks, did this today, so far so good. Thanks a lot for swift relpy!